Wasm lacks stack manipulation ops like dup and swap, making it a register machine with RPN encoding, not a true stack machine.
Key Takeaways
Real stack machines (JVM, Forth) require dup, swap, over, rot to reuse values; Wasm has almost none of these, only drop.
Any non-trivial computation in Wasm forces use of local variables, collapsing the stack abstraction into a register machine.
Binary Wasm uses Reverse Polish notation as an encoding convenience, not because the stack is the primary computational state.
Before the multi-value extension, Wasm control flow blocks could not interact with the outer stack at all, further exposing the register-machine design.
The author’s framing: Wasm is best understood as a register machine where operations are generalized to compound expressions, with RPN as a wire format.
Hacker News Comment Review
Commenters largely agree with the premise: the stack in Wasm is encoding, not semantics, and the absence of dup/swap is a deliberate design constraint tied to the single-pass linear-time validator.
Disagreement surfaced around whether this matters in practice: several commenters note that JVM, the canonical stack machine comparison, also rarely uses stack manipulation in practice, with local variables handling reuse just like Wasm.
A minority view holds that Wasm should have been RISC-V rather than a custom bytecode, questioning the economic rationale for the stack-machine framing entirely.
Notable Comments
@ronin_niron: Wasm’s single-pass linear-time validator requires block-scoped operand stacks with typed signatures at entry/exit, making stack merging across control-flow paths unnecessary by design.
@wabstractions: “Calling Wasm a stack machine is misleading. It’s closer to a structured IR that uses a stack encoding” – the stack is syntax, not semantics.
@stevefan1999: Building a Wasm-to-C compiler, the block-scoped stack guarantee means expression values never need to be discarded mid-evaluation, which the textual S-expression format makes explicit.
