6 ms·

Is there any reason stack-based CPUs fell out of favor? I'm fascinated by RTX2010 [0], a radiation-hardened processor which uses Forth and has been deployed on

Is there any reason stack-based CPUs fell out of favor? I'm fascinated by RTX2010 [0], a radiation-hardened processor which uses Forth and has been deployed on several space missions. [0] https://en.wikipedia.org/wiki/RTX2010 https://en.wikipedia.org/wiki/RTX2010

boesboes 3y ago
I've been reading into this today coincidentally. It seems the main idea was that register based machines are faster, mostly due to the use of local variables in many languages mapping to register and memory latency when the stack is in memory. But that seems to be false based on more recent research. This is a good read on the subject: https://uwspace.uwaterloo.ca/bitstream/handle/10012/10810/LaForest_Eric.pdf?isAllowed=y&sequence=1 https://uwspace.uwaterloo.ca/bitstream/handle/10012/10810/La... Also, check out the GA144: https://www.greenarraychips.com/ https://www.greenarraychips.com/ Also, it's not clear a super scalar stack machine would be possible. So it might not be suitable for replacing x86 soon ;)
- compressedgas 3y ago
  > Also, it's not clear a super scalar stack machine would be possible. The "Boost: Berkeley's Out-of-Order Stack Thingy" (Steve Sinha, Satrajit Chatterjee and Kaushik Ravindran) [1] effectively translates stack code into RISC as part of instruction decoding and issue. This is similar to how "Design of a Superscalar Processor Based on Queue Machine Computation Model" (Shusuke Okamoto, Hitoshi Suzuki, Atusi Maeda, Masahiro Sowa) [2] does the same thing but for a queue machine instead of a stack machine. [1]: https://citeseerx.ist.psu.edu/document?repid=rep1&type=pdf&doi=0366820530b662bd1c3a912720ce23795862d1ba https://citeseerx.ist.psu.edu/document?repid=rep1&type=pdf&d... [2]: https://ieeexplore.ieee.org/document/799499 https://ieeexplore.ieee.org/document/799499
  - ithkuil 3y ago
    Is the "belt" of the Mill CPU a queue architecture or is a queue architecture something else?
    - compressedgas 3y ago
      Yes. The Mill's belt is a queue. The Mill is a queue machine.
  - boesboes 3y ago
    Interesting, thank you! More for the reading list :)
- kragen 3y ago
  the summary of laforest's dissertation says that a small stack machine is much faster (than a presumably in-order MIPS) "for deeply nested or recursive code", but "worse for iterative code" quite aside from the new results it presents, it seems to be a much more comprehensive answer to the question of why stack machines fell out of favor than i've seen before
  - fouc 3y ago
    I've definitely seen that explanation before. I remain slightly skeptical, but that's mostly because I secretly hope stack machines could "win" some day.
    - kragen 3y ago
      i mean the rest of the dissertation, not its abstract
- vanderZwan 3y ago
  Can you give some insight on how the J1 fits in all this? The presentation explaining what drove its invention suggests it actually was faster than the register-based alternative, although I'm sure that is also partially because it only focused on the instructions needed for its task. [0] https://excamera.com/sphinx/article-j1a-swapforth.html https://excamera.com/sphinx/article-j1a-swapforth.html [1] http://www.forth.org/svfig/kk/11-2010-Bowman.pdf http://www.forth.org/svfig/kk/11-2010-Bowman.pdf
  - boesboes 3y ago
    From how I understand the presentation, they ran into trouble because of code size. Basically stack code is much denser because you don't need arguments for registers and, given the 16kbytes -> 6 kbytes is more than just half from going 32->16bit, appearantly a bit more efficient for implementing their program too I guess. The size was a concern because of the limited size (16kbyes) of bram modules on an fpga. I can't say why it performs so much better though, maybe just because it's simpler & 16 bit so it's smaller and can be clocked faster on the fpga? That is just a guess though. I'm not sure if it is fair to compare the J1 to the BOOM, the latter does a lot more I'd think. That being said, it shows that for such use cases a stack machine can be better suited and much less complex to design, maintain and work with.
jasonwatkinspdx 3y ago
Compared to a register machine a stack machine needs to execute extra instructions to shuffle the stack around. If you tried to do something clever to make this superscalar you'd end up with something very much like shadow registers anyhow. I too found Charle's Moore's cpu designs interesting. One possibility I thought about for a bit was a VLIW stack hybrid, where you'd have bundles of say 8 stack instructions each executing concurrently in their own lane, and some instructions for moving values between lanes. It'd be a weird thing to program for, but potentially quite fast for how minimal it'd be.
- sph 3y ago
  Here's Chuck Moore talking about the 144-core CPUs his startup is developing: https://youtu.be/0PclgBd6_Zs https://youtu.be/0PclgBd6_Zs That's an incredible design I would love to get my paws on.
  - jasonwatkinspdx 3y ago
    Oh thanks, I'll check that out. I was musing about this stuff back when reading Hennessy and Patterson in the early 00's. Moore's homepage was really interesting and inspiring, that someone could work idiosyncratically and largely individually and actually get chips to tape out. Cool to hear he's still going strong.
  - kragen 3y ago
    you can just order a ga144 from them last i checked
sph 3y ago
WASM is a stack based "CPU" and arguably the future of the Web. So is Python's. I think also Java and Erlang, but don't quote me on that. A stack based CPU is very easy to implement (or rather, registers are very complex hardware-wise) and a stack-based VM is relatively easy to optimise for a register CPU. Seems to me registers are a fancy hardware implementation detail, that software at higher abstraction can and should avoid unless maximum performance is required. It was surprising for me to learn recently that on modern x86 CPUs, named registers actually reference hidden, dynamically allocated physical registers, a bit like virtual memory is an indirection layer over physical memory. It's levels of indirection all the way down...
- jasonwatkinspdx 3y ago
  So the basic principle is that stack machines have smaller instructions, but require extra instructions to shuffle values around on the stack. This is why register machines won out with hardware, and stack machines are popular for virtual machine intermediate representations (that get compiled or JIT down to register code in the end on basically all machines today). If you wanna learn about how register renaming works, look into Tomasulo's algorithm. State of the art chips are a lot more complex, but that's a good historic introduction to the fundamental ideas.
- runlaszlorun 3y ago
  I’ve been wrestling with WASM bytecode and text format of and on for the last couple years for want of doing something assembly-ish but not wanting to write off doing it for the web. Personally, I’d say it’s at least as much of a register machine as a stack machine and ways in which it is one vs the other at times sure had me running in circles. I’ve seen plenty of quotes about how it’s not supposed to be a real assembly, how you’re not supposed to deal with its text format or bytecode, and how it and its documentation are for compiler writers not typical programmers. Which is exactly the take that I think is so wrong with our status quo of opaque, overly abstracted technologies that are highly optimized in their parts yet so disappointing in the whole. As a Forth substitute, I was sorely disappointed. I did learn a lot in my wanderings, and what WebAssembly is mostly is a an implementation to run a C architecture. Which is pretty much what it came from. Not that I’m against that, but I sure ran in circles trying to make it more Forth-like. And given it’s raison d’etre to be more performant vs Javascript it seems to be faster in some benchmarks while slower in others. I think this is more a testament about how optimized V8 and its brethren are then a slam on WebAssembly.
jacquesm 3y ago
I worked for a company that was building a prototype using the predecessor (the 'NOVIX'), which was incredibly fast for the day.
- DonHopkins 3y ago
  I really wanted one of those! I held one in my hands one time when I was visiting the MIT-AI Lab -- it was Norman Margolus's, who made the CAM-6 with Tommaso Toffoli, which was programmed in Forth. He wouldn't let me have it, but he let my friend and I borrow a CAM-6 for a weekend science fiction convention to trip out on. https://news.ycombinator.com/item?id=8860786 https://news.ycombinator.com/item?id=8860786 https://news.ycombinator.com/item?id=14469113 https://news.ycombinator.com/item?id=14469113 https://news.ycombinator.com/item?id=34561910 https://news.ycombinator.com/item?id=34561910 Rudy Rucker writes about his CAM-6 in the CelLab manual: http://www.fourmilab.ch/cellab/manual/chap5.html http://www.fourmilab.ch/cellab/manual/chap5.html Computer science is still so new that many of the people at the cutting edge have come from other fields. Though Toffoli holds degrees in physics and computer science, Bennett's Ph.D. is in physical chemistry. And twenty-nine year old Margolus is still a graduate student in physics, his dissertation delayed by the work of inventing, with Toffoli, the CAM-6 Cellular Automaton Machine. After watching the CAM in operation at Margolus's office, I am sure the thing will be a hit. Just as the Moog synthesizer changed the sound of music, cellular automata will change the look of video. I tell this to Toffoli and Margolus, and they look unconcerned. What they care most deeply about is science, about Edward Fredkin's vision of explaining the world in terms of cellular automata and information mechanics. Margolus talks about computer hackers, and how a successful program is called “a good hack.” As the unbelievably bizarre cellular automata images flash by on his screen, Margolus leans back in his chair and smiles slyly. And then he tells me his conception of the world we live in. “The universe is a good hack.” [...] Margolus and Toffoli's CAM-6 board was finally coming into production around then, and I got the Department to order one. The company making the boards was Systems Concepts of San Francisco; I think they cost $1500. We put our order in, and I started phoning Systems Concepts up and asking them when I was going to get my board. By then I'd gotten a copy of Margolus and Toffoli's book, Cellular Automata Machines, and I was itching to start playing with the board. And still it didn't come. Finally I told System Concepts that SJSU was going to have to cancel the purchase order. The next week they sent the board. By now it was August, 1987. The packaging of the board was kind of incredible. It came naked, all by itself, in a plastic bag in a small box of styrofoam peanuts. No cables, no software, no documentation. Just a three inch by twelve inch rectangle of plastic—actually two rectangles one on top of the other—completely covered with computer chips. There were two sockets at one end. I called Systems Concepts again, and they sent me a few pages of documentation. You were supposed to put a cable running your graphics card's output into the CAM-6 board, and then plug your monitor cable into the CAM-6's other socket. No, Systems Concepts didn't have any cables, they were waiting for a special kind of cable from Asia. So Steve Ware, one of the SJSU Math&CS Department techs, made me a cable. All I needed then was the software to drive the board, and as soon as I phoned Toffoli he sent me a copy. Starting to write programs for the CAM-6 took a little bit of time because the language it uses is Forth. This is an offbeat computer language that uses reverse Polish notation. Once you get used to it, Forth is very clean and nice, but it makes you worry about things you shouldn't really have to worry about. But, hey, if I needed to know Forth to see cellular automata, then by God I'd know Forth. I picked it up fast and spent the next four or five months hacking the CAM-6. The big turning point came in October, when I was invited to Hackers 3.0, the 1987 edition of the great annual Hackers' conference held at a camp near Saratoga, CA. I got invited thanks to James Blinn, a graphics wizard who also happens to be a fan of my science fiction books. As a relative novice to computing, I felt a little diffident showing up at Hackers, but everyone there was really nice. It was like, “Come on in! The more the merrier! We're having fun, yeeeeee-haw!” I brought my AT along with the CAM-6 in it, and did demos all night long. People were blown away by the images, though not too many of them sounded like they were ready to a) cough up $1500, b) beg Systems Concepts for delivery, and c) learn Forth in order to use a CAM-6 themselves. A bunch of the hackers made me take the board out of my computer and let them look at it. Not knowing too much about hardware, I'd imagined all along that the CAM-6 had some special processors on it. But the hackers informed me that all it really had was a few latches and a lot of fast RAM memory chips.
kragen 3y ago
register machines need to run about half as many instructions on average to do the same thing, which means that at the same clock speed a 1-cycle-per-clock cpu will go about twice as fast with a register instruction set. countering that is that the stack machine doesn't need multiplexers on the inputs to the alu, so it may actually be able to run at a higher clock speed if those multiplexers were part of the critical path, and the stack machine will occupy less silicon area, so you may be able to have more of them (but usually ram takes a lot more area than your cpu) for out-of-order and superscalar processing, register machines have an advantage in that you can more easily have successive instructions that don't interfere, simply by not using the same registers. generally in a stack machine instruction it's hard to avoid using the result of the previous instruction; you need an extra instruction to do it (`over` or `swap` or something) but i suspect it's partly just path-dependence: koopman's new wave of stack machines were already struggling upwind against 30 years of ibm 360, intel 8080, dec pdp-11, motorola 68000, dg nova, sun/fujitsu sparc, etc., all register machines, and so a rich store of knowledge had built up about them in compiler backends, assembly programmers, and cpu designers. maybe if chuck had designed the rtx2010 in 01973 instead of 01988 the story would have been different maybe worth noting that all of the jvm, microsoft's clone of it (the cil), and wasm (as sph pointed out) are stack-based, and arm for a while had a 'jazelle' instruction set which interpreted many jvm bytecodes directly (trapping to software for more complex ones), so in a sense stack-based programs are more widespread now than they ever were before; that's what you see inside a .class file. they just are usually translated into some other instruction set before execution
- kragen 3y ago
  in https://news.ycombinator.com/item?id=37025644 https://news.ycombinator.com/item?id=37025644 boesboes links to https://uwspace.uwaterloo.ca/bitstream/handle/10012/10810/LaForest_Eric.pdf?isAllowed=y&sequence=1 https://uwspace.uwaterloo.ca/bitstream/handle/10012/10810/La... which is a bachelor's of independent studies thesis from several years back which covers the history of stack machines in considerable detail, including, most fascinatingly, zuse's z4, with its 64-word memory, 8-bit instruction tape, and 2-level stack also several people have pointed out that the stack machines most commonly used in practice, including the ones i mentioned above, are hybrids; they have architectural registers (often called local variables) but you have to copy them onto the stack to operate on them

boesboes 3y ago

I've been reading into this today coincidentally. It seems the main idea was that register based machines are faster, mostly due to the use of local variables in many languages mapping to register and memory latency when the stack is in memory. But that seems to be false based on more recent research. This is a good read on the subject: https://uwspace.uwaterloo.ca/bitstream/handle/10012/10810/LaForest_Eric.pdf?isAllowed=y&sequence=1 https://uwspace.uwaterloo.ca/bitstream/handle/10012/10810/La... Also, check out the GA144: https://www.greenarraychips.com/ https://www.greenarraychips.com/ Also, it's not clear a super scalar stack machine would be possible. So it might not be suitable for replacing x86 soon ;)

compressedgas 3y ago
> Also, it's not clear a super scalar stack machine would be possible. The "Boost: Berkeley's Out-of-Order Stack Thingy" (Steve Sinha, Satrajit Chatterjee and Kaushik Ravindran) [1] effectively translates stack code into RISC as part of instruction decoding and issue. This is similar to how "Design of a Superscalar Processor Based on Queue Machine Computation Model" (Shusuke Okamoto, Hitoshi Suzuki, Atusi Maeda, Masahiro Sowa) [2] does the same thing but for a queue machine instead of a stack machine. [1]: https://citeseerx.ist.psu.edu/document?repid=rep1&type=pdf&doi=0366820530b662bd1c3a912720ce23795862d1ba https://citeseerx.ist.psu.edu/document?repid=rep1&type=pdf&d... [2]: https://ieeexplore.ieee.org/document/799499 https://ieeexplore.ieee.org/document/799499
- ithkuil 3y ago
  Is the "belt" of the Mill CPU a queue architecture or is a queue architecture something else?
  - compressedgas 3y ago
    Yes. The Mill's belt is a queue. The Mill is a queue machine.
- boesboes 3y ago
  Interesting, thank you! More for the reading list :)
kragen 3y ago
the summary of laforest's dissertation says that a small stack machine is much faster (than a presumably in-order MIPS) "for deeply nested or recursive code", but "worse for iterative code" quite aside from the new results it presents, it seems to be a much more comprehensive answer to the question of why stack machines fell out of favor than i've seen before
- fouc 3y ago
  I've definitely seen that explanation before. I remain slightly skeptical, but that's mostly because I secretly hope stack machines could "win" some day.
  - kragen 3y ago
    i mean the rest of the dissertation, not its abstract
vanderZwan 3y ago
Can you give some insight on how the J1 fits in all this? The presentation explaining what drove its invention suggests it actually was faster than the register-based alternative, although I'm sure that is also partially because it only focused on the instructions needed for its task. [0] https://excamera.com/sphinx/article-j1a-swapforth.html https://excamera.com/sphinx/article-j1a-swapforth.html [1] http://www.forth.org/svfig/kk/11-2010-Bowman.pdf http://www.forth.org/svfig/kk/11-2010-Bowman.pdf
- boesboes 3y ago
  From how I understand the presentation, they ran into trouble because of code size. Basically stack code is much denser because you don't need arguments for registers and, given the 16kbytes -> 6 kbytes is more than just half from going 32->16bit, appearantly a bit more efficient for implementing their program too I guess. The size was a concern because of the limited size (16kbyes) of bram modules on an fpga. I can't say why it performs so much better though, maybe just because it's simpler & 16 bit so it's smaller and can be clocked faster on the fpga? That is just a guess though. I'm not sure if it is fair to compare the J1 to the BOOM, the latter does a lot more I'd think. That being said, it shows that for such use cases a stack machine can be better suited and much less complex to design, maintain and work with.

jasonwatkinspdx 3y ago

Compared to a register machine a stack machine needs to execute extra instructions to shuffle the stack around. If you tried to do something clever to make this superscalar you'd end up with something very much like shadow registers anyhow. I too found Charle's Moore's cpu designs interesting. One possibility I thought about for a bit was a VLIW stack hybrid, where you'd have bundles of say 8 stack instructions each executing concurrently in their own lane, and some instructions for moving values between lanes. It'd be a weird thing to program for, but potentially quite fast for how minimal it'd be.

sph 3y ago
Here's Chuck Moore talking about the 144-core CPUs his startup is developing: https://youtu.be/0PclgBd6_Zs https://youtu.be/0PclgBd6_Zs That's an incredible design I would love to get my paws on.
- jasonwatkinspdx 3y ago
  Oh thanks, I'll check that out. I was musing about this stuff back when reading Hennessy and Patterson in the early 00's. Moore's homepage was really interesting and inspiring, that someone could work idiosyncratically and largely individually and actually get chips to tape out. Cool to hear he's still going strong.
- kragen 3y ago
  you can just order a ga144 from them last i checked

sph 3y ago

WASM is a stack based "CPU" and arguably the future of the Web. So is Python's. I think also Java and Erlang, but don't quote me on that. A stack based CPU is very easy to implement (or rather, registers are very complex hardware-wise) and a stack-based VM is relatively easy to optimise for a register CPU. Seems to me registers are a fancy hardware implementation detail, that software at higher abstraction can and should avoid unless maximum performance is required. It was surprising for me to learn recently that on modern x86 CPUs, named registers actually reference hidden, dynamically allocated physical registers, a bit like virtual memory is an indirection layer over physical memory. It's levels of indirection all the way down...

jasonwatkinspdx 3y ago
So the basic principle is that stack machines have smaller instructions, but require extra instructions to shuffle values around on the stack. This is why register machines won out with hardware, and stack machines are popular for virtual machine intermediate representations (that get compiled or JIT down to register code in the end on basically all machines today). If you wanna learn about how register renaming works, look into Tomasulo's algorithm. State of the art chips are a lot more complex, but that's a good historic introduction to the fundamental ideas.
runlaszlorun 3y ago
I’ve been wrestling with WASM bytecode and text format of and on for the last couple years for want of doing something assembly-ish but not wanting to write off doing it for the web. Personally, I’d say it’s at least as much of a register machine as a stack machine and ways in which it is one vs the other at times sure had me running in circles. I’ve seen plenty of quotes about how it’s not supposed to be a real assembly, how you’re not supposed to deal with its text format or bytecode, and how it and its documentation are for compiler writers not typical programmers. Which is exactly the take that I think is so wrong with our status quo of opaque, overly abstracted technologies that are highly optimized in their parts yet so disappointing in the whole. As a Forth substitute, I was sorely disappointed. I did learn a lot in my wanderings, and what WebAssembly is mostly is a an implementation to run a C architecture. Which is pretty much what it came from. Not that I’m against that, but I sure ran in circles trying to make it more Forth-like. And given it’s raison d’etre to be more performant vs Javascript it seems to be faster in some benchmarks while slower in others. I think this is more a testament about how optimized V8 and its brethren are then a slam on WebAssembly.

jacquesm 3y ago

I worked for a company that was building a prototype using the predecessor (the 'NOVIX'), which was incredibly fast for the day.

DonHopkins 3y ago
I really wanted one of those! I held one in my hands one time when I was visiting the MIT-AI Lab -- it was Norman Margolus's, who made the CAM-6 with Tommaso Toffoli, which was programmed in Forth. He wouldn't let me have it, but he let my friend and I borrow a CAM-6 for a weekend science fiction convention to trip out on. https://news.ycombinator.com/item?id=8860786 https://news.ycombinator.com/item?id=8860786 https://news.ycombinator.com/item?id=14469113 https://news.ycombinator.com/item?id=14469113 https://news.ycombinator.com/item?id=34561910 https://news.ycombinator.com/item?id=34561910 Rudy Rucker writes about his CAM-6 in the CelLab manual: http://www.fourmilab.ch/cellab/manual/chap5.html http://www.fourmilab.ch/cellab/manual/chap5.html Computer science is still so new that many of the people at the cutting edge have come from other fields. Though Toffoli holds degrees in physics and computer science, Bennett's Ph.D. is in physical chemistry. And twenty-nine year old Margolus is still a graduate student in physics, his dissertation delayed by the work of inventing, with Toffoli, the CAM-6 Cellular Automaton Machine. After watching the CAM in operation at Margolus's office, I am sure the thing will be a hit. Just as the Moog synthesizer changed the sound of music, cellular automata will change the look of video. I tell this to Toffoli and Margolus, and they look unconcerned. What they care most deeply about is science, about Edward Fredkin's vision of explaining the world in terms of cellular automata and information mechanics. Margolus talks about computer hackers, and how a successful program is called “a good hack.” As the unbelievably bizarre cellular automata images flash by on his screen, Margolus leans back in his chair and smiles slyly. And then he tells me his conception of the world we live in. “The universe is a good hack.” [...] Margolus and Toffoli's CAM-6 board was finally coming into production around then, and I got the Department to order one. The company making the boards was Systems Concepts of San Francisco; I think they cost $1500. We put our order in, and I started phoning Systems Concepts up and asking them when I was going to get my board. By then I'd gotten a copy of Margolus and Toffoli's book, Cellular Automata Machines, and I was itching to start playing with the board. And still it didn't come. Finally I told System Concepts that SJSU was going to have to cancel the purchase order. The next week they sent the board. By now it was August, 1987. The packaging of the board was kind of incredible. It came naked, all by itself, in a plastic bag in a small box of styrofoam peanuts. No cables, no software, no documentation. Just a three inch by twelve inch rectangle of plastic—actually two rectangles one on top of the other—completely covered with computer chips. There were two sockets at one end. I called Systems Concepts again, and they sent me a few pages of documentation. You were supposed to put a cable running your graphics card's output into the CAM-6 board, and then plug your monitor cable into the CAM-6's other socket. No, Systems Concepts didn't have any cables, they were waiting for a special kind of cable from Asia. So Steve Ware, one of the SJSU Math&CS Department techs, made me a cable. All I needed then was the software to drive the board, and as soon as I phoned Toffoli he sent me a copy. Starting to write programs for the CAM-6 took a little bit of time because the language it uses is Forth. This is an offbeat computer language that uses reverse Polish notation. Once you get used to it, Forth is very clean and nice, but it makes you worry about things you shouldn't really have to worry about. But, hey, if I needed to know Forth to see cellular automata, then by God I'd know Forth. I picked it up fast and spent the next four or five months hacking the CAM-6. The big turning point came in October, when I was invited to Hackers 3.0, the 1987 edition of the great annual Hackers' conference held at a camp near Saratoga, CA. I got invited thanks to James Blinn, a graphics wizard who also happens to be a fan of my science fiction books. As a relative novice to computing, I felt a little diffident showing up at Hackers, but everyone there was really nice. It was like, “Come on in! The more the merrier! We're having fun, yeeeeee-haw!” I brought my AT along with the CAM-6 in it, and did demos all night long. People were blown away by the images, though not too many of them sounded like they were ready to a) cough up $1500, b) beg Systems Concepts for delivery, and c) learn Forth in order to use a CAM-6 themselves. A bunch of the hackers made me take the board out of my computer and let them look at it. Not knowing too much about hardware, I'd imagined all along that the CAM-6 had some special processors on it. But the hackers informed me that all it really had was a few latches and a lot of fast RAM memory chips.

kragen 3y ago

register machines need to run about half as many instructions on average to do the same thing, which means that at the same clock speed a 1-cycle-per-clock cpu will go about twice as fast with a register instruction set. countering that is that the stack machine doesn't need multiplexers on the inputs to the alu, so it may actually be able to run at a higher clock speed if those multiplexers were part of the critical path, and the stack machine will occupy less silicon area, so you may be able to have more of them (but usually ram takes a lot more area than your cpu) for out-of-order and superscalar processing, register machines have an advantage in that you can more easily have successive instructions that don't interfere, simply by not using the same registers. generally in a stack machine instruction it's hard to avoid using the result of the previous instruction; you need an extra instruction to do it (`over` or `swap` or something) but i suspect it's partly just path-dependence: koopman's new wave of stack machines were already struggling upwind against 30 years of ibm 360, intel 8080, dec pdp-11, motorola 68000, dg nova, sun/fujitsu sparc, etc., all register machines, and so a rich store of knowledge had built up about them in compiler backends, assembly programmers, and cpu designers. maybe if chuck had designed the rtx2010 in 01973 instead of 01988 the story would have been different maybe worth noting that all of the jvm, microsoft's clone of it (the cil), and wasm (as sph pointed out) are stack-based, and arm for a while had a 'jazelle' instruction set which interpreted many jvm bytecodes directly (trapping to software for more complex ones), so in a sense stack-based programs are more widespread now than they ever were before; that's what you see inside a .class file. they just are usually translated into some other instruction set before execution

kragen 3y ago
in https://news.ycombinator.com/item?id=37025644 https://news.ycombinator.com/item?id=37025644 boesboes links to https://uwspace.uwaterloo.ca/bitstream/handle/10012/10810/LaForest_Eric.pdf?isAllowed=y&sequence=1 https://uwspace.uwaterloo.ca/bitstream/handle/10012/10810/La... which is a bachelor's of independent studies thesis from several years back which covers the history of stack machines in considerable detail, including, most fascinatingly, zuse's z4, with its 64-word memory, 8-bit instruction tape, and 2-level stack also several people have pointed out that the stack machines most commonly used in practice, including the ones i mentioned above, are hybrids; they have architectural registers (often called local variables) but you have to copy them onto the stack to operate on them