39 ms·
Contrary to much common misunderstanding, sure, no real problem. The semantics of each instruction is consume the two top stack elements and replace that with
by FullyFunctional 6y ago
Contrary to much common misunderstanding, sure, no real problem.
The semantics of each instruction is consume the two top stack elements and replace that with the results. You handle this by having an stack rename stack of physical registers (with additional complication for handling under- and overflows), that is assuming the current stack is
pr3 pr4 pr5
and the first free register is pr56
Then an "+" instruction is interpreted as "add pr56, pr4, pr5" and pr56 is consumed and pr4 and pr5 marked to be freed when this commits.
Because stack machines inherently introduce a lot of tight dependencies you will need to use dynamic scheduling (OoOE) to go super-scalar, but it's not a problem.
Upsides are incredible instruction density. Downside: slightly harder to do good code generation, but not really.
- klelatti 6y agoThank you for an interesting answer. This begs the question of course: why have they never caught on?
- deleted 6y ago[deleted]
- FullyFunctional 6y agoI'm assuming partly inertia, partly the code density not being important enough to do this. To be clear, while you _can_ go OoO superscalar with a stack machine, it's more work than with an ISA that exposes the dependencies, like VLIW or EDGE. Don't take my word for it, design, model, simulate, and implement it yourself. It's a small matter of coding. EDIT: Reduceron is an example of a super-scalar stack machine, though not dynamically scheduled. It's very difficult to write code by hand though.
- klelatti 6y agoThanks - the Reduceron looks really interesting.