7 ms·
Stack Computers: the new wave (1989)
- kasajian 10y agoAre we going back to programming in Forth now?
- pkaye 10y agoOnce or twice a month Forth and Lisp posts get repeated...
- GFK_of_xmaspast 10y agoThere's lisp posts here all the time, but forth posts are regrettably sporadic.
- dbcurtis 10y agoSo 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 10y agoThis is the premise of the Mill architecture; though I haven't heard from them for a while now.
- dbcurtis 10y agoReally? The stuff I've seen about Mill is that they are doing a VLIW machine, which is a very different concept.
- lmitchell 10y agoWhile 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/
- pkaye 10y agoI don't know why the mill architecture has not gone into production yet. That technology has been in development for 13 years. It brings forth some interesting ideas. What is holding them back?
- honkhonkpants 10y agoIsn't is a volunteer effort?
- pkaye 10y agoIt is a startup though the degree of funding is not clear.
- vertex-four 10y ago
- amelius 10y agoAfaik, the Java virtual machine is also heavily stack-based.
- tamana 10y agoIs that relevant to the hardware implementation though?
- protomyth 10y agoI seem to remember that the attempts at implementing the JVM in hardware haven't worked out all that well and the stack implementation was blamed for their inability to beat a software implementation on x86. I wonder if anyone here has more information or personal experience?
- pag 10y agoThere'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
- TempleOSV409 10y agoMost 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 10y agoHi Terry, Do you have a document describing the stack machine intermediate code for TempleOS?
- awful 10y ago"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.
- rhizome 10y agoI've been waiting for a stack computer with a GaAs CPU and bubble memory for I don't know how long!
- mud_dauber 10y agoI 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.