5 ms·

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 i

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.

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.