New soft processor core paper publisher?

On 6/13/2013 1:07 PM, Eric Wallin wrote:
> Thank you for your reply Nikolaos!
>
>> This reads like a "fourstack" architecture on steroids. It seems
>> good!
>
> "A Four Stack Processor" by Bernd Paysan?  I ran across that paper several years ago (thanks!).  Very interesting, but with multiple ALUs, access to data below the LIFO tops, TLBs, security, etc. it is much more complex than my processor.  It looks like a real bear to program and manage at the lowest level.
>
>> How do you compare with more classic RISC-like soft-cores like
>> MicroBlaze, Nios-II, LEON, etc?
>
> The target audience for my processor is an FPGA developer who needs to implement complex functionality that tolerates latency but requires deterministic timing.  Hand coding with no toolchain (verilog initial statement boot code).  Simple enough to keep the processor model and current state in one's head (with room to spare).  Small enough to fit in the smallest of FPGAs (with room to spare).  Not meant at all to run a full-blown OS, but not a trivial processor.

That the ground I have been plowing off and on for the last 10 years.


>> There is also a classic book on stack-based computers, you really need
>> to go through this and reference it in your publication.
>
> "Stack Computers: The New Wave" by Philip J. Koopman, Jr.?  Also ran across that many years ago (thanks!).  The main thrust of it seems to be the advocating of single data stack, single return stack, zero operand machines, which I feel (nothing personal) are crap.  Easy to design and implement (I've made several while under the spell) but impossible to program in an efficient manner (gobs of real time wasted on stack thrash, the minimization of which leads directly to unreadable procedural coding practices, which leads to catastrophic stack faults).

I assume that you do understand that the point of MISC is that the 
implementation can be minimized so that the instructions run faster.  In 
theory this makes up for the extra instructions needed to manipulate the 
stack on occasion.  But I understand your interest in minimizing the 
inconvenience of stack ops.  I spent a little time looking at 
alternatives and am currently looking at a stack CPU design that allows 
offsets into the stack to get around the extra stack ops.  I'm not sure 
how this compares to your ideas.  It is still a dual stack design as I 
have an interest in keeping the size of the implementation at a minimum. 
  1800 LEs won't even fit on the FPGAs I am targeting.


> My processor incorporates what I believe are a couple of new innovations (but who ever really knows?) that I'd like to get out there if possible.  And I wouldn' mind a bit of personal recognition if only for my efforts.

I would like to hear about your innovations.  As you seem to understand, 
it is hard to be truly innovative finding new ideas that others have not 
uncovered.  But I think you are certainly in an area that is not 
thoroughly explored.


> IEEE is probably out.  I fundamentally disagree with the hoarding of tecnical papers behind a greedy paywall.

I won't argue with that.  Even when I was an IEEE member, I never found 
a document I didn't have to pay for.

When can we expect to see your paper?

-- 

Rick

Thanks for your response rickman!

On Saturday, June 15, 2013 8:40:27 PM UTC-4, rickman wrote:
> That the ground I have been plowing off and on for the last 10 years.

Ooo, same here, and my condolences.  I caught a break a couple of months ag=
o and have been beavering away on it ever since, and I finally have somethi=
ng that doesn't cause me to vomit when I code for it.  Multiple indexed sim=
ple stacks with explicit pointer control makes everything a lot easier than=
 a bog standard stack machine.  I think the auto-consumption of literally e=
verything, particularly the data, indexes, and pointers you dearly want to =
use again is at the bottom of all the crazy people just accept with stack m=
achines.  This mechanism works great for manual data entry on HP calculator=
s, but not so much for stack machines IMHO.  Auto consumption also pretty m=
uch rules out conditional execution of single instructions.

> I assume that you do understand that the point of MISC is that the=20
> implementation can be minimized so that the instructions run faster.  In=
=20
> theory this makes up for the extra instructions needed to manipulate the=
=20
> stack on occasion.  But I understand your interest in minimizing the=20
> inconvenience of stack ops.  I spent a little time looking at=20
> alternatives and am currently looking at a stack CPU design that allows=
=20
> offsets into the stack to get around the extra stack ops.  I'm not sure=
=20
> how this compares to your ideas.  It is still a dual stack design as I=20
> have an interest in keeping the size of the implementation at a minimum.=
=20

MISC is interesting, but you have to consider that all ops, including simpl=
e stack manipulations, will generally consume as much real time as a multip=
ly, which suddenly makes all of those confusing stack gymnastics you have t=
o perform to dig out your loop index or whatever from underneath your read/=
write pointer from underneath your data and such overly burdensome.

Indexes into a moving stack - that way lies insanity.  Ever hit the roll do=
wn button on an HP calculator and get instantly flummoxed?  Maybe a compile=
r can keep track of that kind of stuff, but my weak brain isn't up to the t=
ask.

Altera BRAM doesn't go as wide as Xilinx with true dual port.  When I was w=
orking in Xilinx I was able to use a single BRAM for both the data and retu=
rn stacks (16 bit data).

>   1800 LEs won't even fit on the FPGAs I am targeting.

I'm not sure anything less than the smallest Cyclone 2 is really worth deve=
loping in.  A lot of the stuff below that is often more expensive due to th=
e built-in configuration memory and such.  There are quite inexpensive Cycl=
one dev boards on eBay from China.

> I would like to hear about your innovations.  As you seem to understand,=
=20
> it is hard to be truly innovative finding new ideas that others have not=
=20
> uncovered.  But I think you are certainly in an area that is not=20
> thoroughly explored.

I haven't seen anything exactly like it, certainly not the way the stacks a=
re implemented.  And I deal with extended arithmetic results in an unusual =
way.  In terms of scheduling and pipelining, the Parallax Propeller is prob=
ably the closest in architecture (you can infer from the specs and operatio=
nal model what they don't explicitly tell you in the datasheet).

> I won't argue with that.  Even when I was an IEEE member, I never found=
=20
> a document I didn't have to pay for.

I was a member too right out of grad school.  But, like Janet Jackson sang:=
 "What have they done for me lately?"

> When can we expect to see your paper?

It's all but done, just picking around the edges at this point.  As soon as=
 the code is verified to my satisfaction I'll release both and post here.

Eric Wallin wrote:

> Indexes into a moving stack - that way lies insanity.  Ever hit the roll down button on an HP calculator and get instantly flummoxed?  Maybe a compiler can keep track of that kind of stuff, but my weak brain isn't up to the task.

Have a look at comp.arch, in particular the current discussion about the "belt" in the Mill processor. Start by watching the video.

The Mill is a radical architecture that offers far greater instruction level parallelism than existing processors, partly by having no general purpose registers.

The Mill is irrelevant to FPGA processors; it is aimed at beating x86 machines.

On Sunday, June 16, 2013 5:23:01 AM UTC-4, Tom Gardner wrote:

> The Mill is irrelevant to FPGA processors...

The Mill looks vaguely interesting (if you're into billion transistor processors) but as you indicated I'm not sure how it is relevant to this thread?

Eric Wallin wrote:
> On Sunday, June 16, 2013 5:23:01 AM UTC-4, Tom Gardner wrote:
>
>> The Mill is irrelevant to FPGA processors...
>
> The Mill looks vaguely interesting (if you're into billion transistor processors) but as you indicated I'm not sure how it is relevant to this thread?

You wrote "Indexes into a moving stack - that way lies insanity."
The Mill's belt is effectively exactly that, and they appear not to have gone insane.

On Sunday, June 16, 2013 1:16:42 PM UTC-4, Tom Gardner wrote:

> You wrote "Indexes into a moving stack - that way lies insanity."
> The Mill's belt is effectively exactly that, and they appear not to have gone insane.

I bet they would if they tried to hand code it in assembly! ;-)

The first video comment is priceless: "Gandalf?"

Eric Wallin wrote:
> On Sunday, June 16, 2013 1:16:42 PM UTC-4, Tom Gardner wrote:
>
>> You wrote "Indexes into a moving stack - that way lies insanity."
>> The Mill's belt is effectively exactly that, and they appear not to have gone insane.
>
> I bet they would if they tried to hand code it in assembly! ;-)

It *is* considerably easier than hand-coding Itanium. With that
you change *any* aspect of the microarchitecture and you go back
to the beginning. How do I know? I asked someone that was doing
it to assess its performance, and decided to Run Away from
anything to do with the Itanium.


> The first video comment is priceless: "Gandalf?"

How shallow :)

On 6/15/2013 10:17 PM, Eric Wallin wrote:
> Thanks for your response rickman!
>
> On Saturday, June 15, 2013 8:40:27 PM UTC-4, rickman wrote:
>> That the ground I have been plowing off and on for the last 10 years.
>
> Ooo, same here, and my condolences.  I caught a break a couple of months ago and have been beavering away on it ever since, and I finally have something that doesn't cause me to vomit when I code for it.  Multiple indexed simple stacks with explicit pointer control makes everything a lot easier than a bog standard stack machine.  I think the auto-consumption of literally everything, particularly the data, indexes, and pointers you dearly want to use again is at the bottom of all the crazy people just accept with stack machines.  This mechanism works great for manual data entry on HP calculators, but not so much for stack machines IMHO.  Auto consumption also pretty much rules out conditional execution of single instructions.

I was looking at how to improve a stack design a few months ago and came 
to a similar conclusion.  My first attempt at getting around the stack 
ops was to use registers.  I was able to write code that was both 
smaller and faster since in my design all instructions are one clock 
cycle so executed instruction count equals number of machine cycles. 
Well, sort of.  My original dual stack design was literally one clock 
per instruction.  In order to work with clocked block ram the register 
machine would use either both phases of two clocks per machine cycle or 
four clock cycles.

While pushing ideas around on paper, the J1 design gave me an idea of 
adjusting the stack point as well as using an offset in each 
instruction.  That gave a design that is even faster with fewer 
instructions.  I'm not sure if it is practical in a small opcode.  I 
have been working with 8 and 9 bit opcodes, the latest approach with 
stack pointer control can fit in 9 bits, but would be happier with a 
couple more bits.


>> I assume that you do understand that the point of MISC is that the
>> implementation can be minimized so that the instructions run faster.  In
>> theory this makes up for the extra instructions needed to manipulate the
>> stack on occasion.  But I understand your interest in minimizing the
>> inconvenience of stack ops.  I spent a little time looking at
>> alternatives and am currently looking at a stack CPU design that allows
>> offsets into the stack to get around the extra stack ops.  I'm not sure
>> how this compares to your ideas.  It is still a dual stack design as I
>> have an interest in keeping the size of the implementation at a minimum.
>
> MISC is interesting, but you have to consider that all ops, including simple stack manipulations, will generally consume as much real time as a multiply, which suddenly makes all of those confusing stack gymnastics you have to perform to dig out your loop index or whatever from underneath your read/write pointer from underneath your data and such overly burdensome.

Programming to facilitate stack optimization is king on a stack machine. 
  I'm not sure how the multiply speed is relevant, but the real question 
is just how fast does an algorithm run which has to include all the 
instructions needed as well as the clock speed.  Then it is also 
important to consider resources used.  I think you said your design uses 
1800 LEs which is a *lot* more than a simple two stack design.  They 
aren't always available.


> Indexes into a moving stack - that way lies insanity.  Ever hit the roll down button on an HP calculator and get instantly flummoxed?  Maybe a compiler can keep track of that kind of stuff, but my weak brain isn't up to the task.

Then I don't know why you are designing CPUs, lol!  I like RPN 
calculators and have trouble using anything else.  I also program in 
Forth so this all works for me.


> Altera BRAM doesn't go as wide as Xilinx with true dual port.  When I was working in Xilinx I was able to use a single BRAM for both the data and return stacks (16 bit data).

I expect Xilinx has some patent that Altera can't get around for a 
couple more years.  Lattice seems to be pretty good though.  I just 
would prefer to have an async read since that works in a one clock 
machine cycle better.


>>    1800 LEs won't even fit on the FPGAs I am targeting.
>
> I'm not sure anything less than the smallest Cyclone 2 is really worth developing in.  A lot of the stuff below that is often more expensive due to the built-in configuration memory and such.  There are quite inexpensive Cyclone dev boards on eBay from China.

I don't know about dev board cost, but I can get a 1280 LUT Lattice part 
for under $4 in reasonable quantity.  That is the area I typically work 
in.  My big problem is packages.  I don't want to have to use extra fine 
pitch on PCBs to avoid the higher costs.  BGAs require very fine via 
holes and fine pitch PCB traces and run the board costs up a bit.  None 
of the FPGA makers support the parts I like very well.  VQ100 is my 
favorite, small but enough pins for most projects.


>> I would like to hear about your innovations.  As you seem to understand,
>> it is hard to be truly innovative finding new ideas that others have not
>> uncovered.  But I think you are certainly in an area that is not
>> thoroughly explored.
>
> I haven't seen anything exactly like it, certainly not the way the stacks are implemented.  And I deal with extended arithmetic results in an unusual way.  In terms of scheduling and pipelining, the Parallax Propeller is probably the closest in architecture (you can infer from the specs and operational model what they don't explicitly tell you in the datasheet).
>
>> I won't argue with that.  Even when I was an IEEE member, I never found
>> a document I didn't have to pay for.
>
> I was a member too right out of grad school.  But, like Janet Jackson sang: "What have they done for me lately?"

My mistake was getting involved in the local chapters.  Seems IEEE is 
just a good ol' boys network and is all about status and going along to 
get along.  They don't believe in the written rules, more so the 
unwritten ones.


>> When can we expect to see your paper?
>
> It's all but done, just picking around the edges at this point.  As soon as the code is verified to my satisfaction I'll release both and post here.

Ok, looking forward to it.

-- 

Rick

On Wednesday, June 19, 2013 5:13:04 PM UTC-4, rickman wrote:

> While pushing ideas around on paper, the J1 design gave me an idea of=20
> adjusting the stack point as well as using an offset in each=20
> instruction.  That gave a design that is even faster with fewer=20
> instructions.  I'm not sure if it is practical in a small opcode. =20

Interesting.  The J1 strongly influenced me as well.

< I have been working with 8 and 9 bit opcodes, the latest approach with=20
> stack pointer control can fit in 9 bits, but would be happier with a=20
> couple more bits.

I decided to stay away from non-powers of 2 widths for instructions and dat=
a.  Not efficient in standard storage.  Having multiple instructions per wo=
rd I see now as more of a bug than a feature because you have to index into=
 it to return from a subroutine and how / where do you store the index?

> Programming to facilitate stack optimization is king on a stack machine.=
=20

I feel that this is a fiddly activity that wastes the programmer's time and=
 creates code that is exceedingly difficult to figure out later.

>   I'm not sure how the multiply speed is relevant, but the real question=
=20
> is just how fast does an algorithm run which has to include all the=20
> instructions needed as well as the clock speed.

Multiply is relevant because in a 32 bit machine it will likely be THE spee=
d bottleneck, pulling overall timing down.  They include non-fabric registe=
ring at the I/O of the FPGA multiply hardware to help pipeline it.  Same wi=
th BRAM - reads really speed up if you use the "free" output registering (i=
n addition to the synchronous register you are generally forced to use).

> > Indexes into a moving stack - that way lies insanity.  Ever hit the rol=
l down button on an HP calculator and get instantly flummoxed?  Maybe a com=
piler can keep track of that kind of stuff, but my weak brain isn't up to t=
he task.
>=20
> Then I don't know why you are designing CPUs, lol!  I like RPN=20
> calculators and have trouble using anything else.  I also program in=20
> Forth so this all works for me.

Quite the contrary, I've used HP calculators religiously since I won one in=
 a HS engineering contest almost 30 years ago.  Too bad they don't make the=
 "real" ones anymore (35S is the best they can do it seems, maybe they lost=
 the plans along with those of the Saturn V).  But when I hit the roll down=
 button to find a value on the stack, I have to give up on the other stack =
items due to confusion.  I really want to like Forth, but after reading the=
 books and being repeatedly repelled by the syntax and programming model I =
gave up.

My goal with CPU design was to make one simple enough to program without sp=
ecial tools, but complex enough to do real work and I think I've finally ac=
hieved that.

> I expect Xilinx has some patent that Altera can't get around for a=20
> couple more years.  Lattice seems to be pretty good though.  I just=20
> would prefer to have an async read since that works in a one clock=20
> machine cycle better.

I like Lattice parts too, and used the original MachXO on many boards in li=
eu of a CPLD. =20

But I gave up on single cycle along with two stacks and autoconsumption.  L=
ike you say async read BRAM is hard to come by.  Single cycle is also slow =
and strands a bazillion FFs in the fabric.

I wonder if you've read this article:

http://spectrum.ieee.org/semiconductors/processors/25-microchips-that-shook=
-the-world

Moore made a lot of money off of what seem like frivolous lawsuits, which b=
rings him down several notches in my eyes.

Eric Wallin wrote:
> Quite the contrary, I've used HP calculators religiously since
 > I won one in a HS engineering contest almost 30 years ago.
 > Too bad they don't make the "real" ones anymore (35S is the
 > best they can do it seems, maybe they lost the plans along
 > with those of the Saturn V).

I'm sure HP still has the plans for the Saturn, viz
http://www.hpmuseum.org/saturn.htm

Sorry, couldn't resist.


 > I really want to like Forth, but after reading the books
 > and being repeatedly repelled by the syntax and programming
 > model I gave up.

Nobody /writes/ Forth. They write programs that emit Forth.
The most mainstream example of that is printer drivers
emitting PostScript.