
Stack Computers: the new wave (1989) - kercker
https://users.ece.cmu.edu/~koopman/stack_computers/
======
awful
"Burroughs Machines: Implementation: A series of minicomputers" This is
misleading; these were often very well regarded military grade and size, 48/51
bit stack based machines, hundreds of disk spindles and massive I/O, up to 8
CPU symmetric multiprocessing (7 IIRC cause you needed an I/O cabinet). And a
sophisticated OS called MCP. Virtual memory. In 1977, or 1969, or earlier.
[https://en.wikipedia.org/wiki/Burroughs_large_systems](https://en.wikipedia.org/wiki/Burroughs_large_systems)
Datamation archives tell the story.

------
pag
There's some pretty cool references here [1] from a former TA of mine.

[1] [http://fpgacpu.ca/stack/index.html](http://fpgacpu.ca/stack/index.html)

------
kasajian
Are we going back to programming in Forth now?

~~~
dbcurtis
So going back to Forth is probably not a good idea, but consider this....

1\. Modern CPU microarchitectures issue multiple instructions/micro-
instructions per clock.

2\. Modern CPU microarchitectures rely heavily on register renaming in order
to avoid bottlenecking on register allocation.

3\. High code density is a huge win because: a) highly dense code reduces the
cache footprint for a given amount of expressed functionality, which in turn
reduces the amount of die area that need be dedicated to instruction cache in
a well-balanced processor. b) highly dense code reduces the amount of bus
traffic filling the instruction cache from main memory, thus reducing the
overall memory bandwidth required to execute a given amount of functionality.
Taking a & b together, they explain, in part, why X86 is still king of the
hill, and it certainly explains why X86 won over Itanium. X86 code, for all
its accumulated cruft, is very dense.

4\. Stack machine code is also very dense, because exactly zero bits are
dedicated to register names in every instruction.

So... given that the register numbers in typical 2-address or 3-address
machines are getting renamed away anyway, why have them at all? Let the
compiler generate 0-address code for a stack machine, and let the instruction
decoder parse a long string of tokens during a single clock, using standard
register renaming techniques to assign virtual stack locations from a large
buffer pool. It could issue multiple stack ops per clock, but unwound into
simple 3-address micro-ops for the CPU back end. It's really just the final
step in moving the register allocator from the compiler to the CPU.

These are all solved problems for the X86 instruction set. Given that
existence proof, it is difficult to argue that it would be hard to do for a
clean stack-machine ISA.

~~~
microcolonel
This is the premise of the Mill architecture; though I haven't heard from them
for a while now.

~~~
dbcurtis
Really? The stuff I've seen about Mill is that they are doing a VLIW machine,
which is a very different concept.

~~~
lmitchell
While I think that's true, it's also orthogonal to the 'belt' concept [1]
they're using, which I think GP was referring to.

I'm also curious about the state of the Mill - judging by the forums on their
website they've been basically dark for about a year and a half now, though
Ivan Godard claims that everything is still moving along, just slightly slower
than expected.

[1]
[https://millcomputing.com/docs/belt/](https://millcomputing.com/docs/belt/)

------
mud_dauber
I joined Harris Semiconductors' RTX2000 dev team after grad school & helped
customers benchmark code using hand-built assembly language.

It was a ton of fun explaining stack ops to x86 designers :), plus the
architecture ran rings around competitors' microcontrollers. Alas, cool
architectures do not guarantee design wins.

------
rhizome
I've been waiting for a stack computer with a GaAs CPU and bubble memory for I
don't know how long!

------
TempleOSV409
Most compilers use AST for internal intermediate code. TempleOS uses a stack
machine intermediate code. At the end, it converts from intermediate code to
x86_64 machine code.

~~~
analognoise
Hi Terry, Do you have a document describing the stack machine intermediate
code for TempleOS?

