Stack Computers: the new wave (1989)

https://en.m.wikipedia.org/wiki/Java_processor

https://en.m.wikipedia.org/wiki/Jazelle

This later inspired HP for the HP 3000 and then its RPN calculators, as well as other, lesser known machines. Nowadays I think I've only seen this with the JVM (to reduce the IL size) and a couple MCUs.

I have no proof of this and I am not a processor designer. Just a hunch that this kind of analysis would be harder to perform on a stack oriented program flow.

Why not cache the top N words then?

Stacks are local to a CPU, so you don't have to deal with coherence.

I think the conventional view on designs like the MuP21 and the 8087 is that they don't scale because they are bad at supporting out-of-order execution, because every instruction has a data dependency on the previous instruction. But if I'm reading https://stackoverflow.com/questions/18138382/which-registers... correctly, it says that in fact the 8087 instructions have decent performance even on current amd64 processors.

Stack computers do tend to have smaller code size than register machines, but a direct comparison of, say, 16 bits for RVC or Thumb instructions vs. 5 bits for GA144 x18 instructions is a little bit misleading, because you usually end up running about twice as many instructions to do the same job. So you end up saving about a third of your code space, not the two thirds you'd naively expect. Compensatorily you need about twice the clock speed to get the same performance.

Chuck Moore says you can get a higher clock speed because you can wire your ALU inputs directly to the top-of-stack and next-on-stack registers, so you don't have operand field decoding and register-file demultiplexing in your critical path. (But then he went off and gave up on clocks altogether in the x18, which is entirely asynchronous.) The attention the RISC-V designers gave to keeping the operand fields in the same place in every instruction format, even in RVC, reinforces my perception that this is still a live issue, not a holdover from the early 90s.

Maybe this is a personal problem stemming from lack of experience, but I still find stack code more bug-prone and harder to read than register-machine assembly languages.

BTW SeRV implements RISC-V in under 200 LUTs, and 4-LUTs at that, but the ZPU is probably faster.

On a register machine, duplicating a value is implicit (it happens implicitly every time you read it) but operand choice is explicit. On a stack machine, duplicating a value is explicit (with DUP or OVER, for example) but operand choice is implicit. A stack is sort of like a register that can hold more than one value, but in which each value pushed must normally be used exactly once.

As I understand it, the F18's operand stack has ten items, of which eight are cyclic: TOS, NOS, and eight more. Presumably the other eight items are cyclic because pushing and popping them is implemented by incrementing and decrementing a counter. But this still takes less area than a multi-ported register file; Shirriff's reverse-engineering of the 8086 found that its register file had three read ports and one write port, so the pass transistors for the muxing took up more area than the inverter transistors that implemented the memory bits themselves!

https://www.realworldtech.com/forum/?threadid=207836&curpost...

If you mean "can be rapidly deployed from bare metal to a rich and complex application stack" then they scale out quite well, because a stack-based architecture - or even an architecture that lends itself to implementing stack-based languages, like the Motorola 6809 - kind of points you in the direction of Forth, and once you've decided you're using Forth then you've only to write a few dozen lines of assembly and the rest of your Forth is written in Forth.

The stack machines book is the only computer architecture book I've read cover to cover.