WASM is not quite a stack machine • Hacker News Board

Re: WASM is not quite a stack machine

#21

Post by pjjpo » Tue, Apr 28, 2026, 11:52 AM UTC

purplesyringa wrote: post #18

asibahi wrote: post #11

I dont really disagree with the main premise of the article, which is that WASM is not really a stack language , but this part just gave me pause: > In textual Wasm, for example, they are instead represented in a LISP-like notation – not any less or more efficient The Text format, at least when it comes to instructions, it 1 to 1 with the binary format. The LISP-like syntax is mainly just syntax sugar[1]. ‘(’ plainin…

> tl;dr: the LISP syntax is just syntax sugar. The textual format is as "stack-like" as the binary format. Not that you're technically wrong, but I think you're begging the question. Stack-based languages/encodings, in a colloquial sense, are equated to postfix notation, e.g. `a b +` instead of the infix `a + b`. Both LISP and textual Wasm use prefix notation, e.g. `(+ a b)`. Neither of the three is any more foundati…

I have reread this several times but might be missing so I am begging the question, what exactly makes the LISP syntax sugar for something that isn't a stack machine? Or did I misread that?

If not, I think the OP is making the same point we all are, any program can be translated for execution on any machine - so bringing it up in the blog seems weak, which I agree with.

Re: WASM is not quite a stack machine

#22

Post by sippeangelo » Tue, Apr 28, 2026, 11:53 AM UTC

shevy-java wrote: post #14

I am sad about WASM. It was a promise for epic greatness. It has failed to deliver that - so much is clear now. You rarely see any awesome success story shown with regard to WASM nowadays. What happened to the old promises? "Electron will be SUPER fast thanks to WASM" or "use any language, WASM unifies it all for the larger browser ecosystem". It feels as if WASM is on a step towards exctinction. Sure, it is mentione…

Just recently I've compiled my side-project Rust game engine to WASM and it runs beautifully in the browser, as well as SSH2 to have a fully featured SSH implementation in the browser over a websocket transport.

It can obviously do amazing things, but the expectation for it to do replace webdev frontend code was always a huge misconception. Though recent developments have made DOM access without a JavaScript translation layer possible, so that might change!

I'd say the hype is still very much alive.

Re: WASM is not quite a stack machine

#23

Post by asibahi » Tue, Apr 28, 2026, 11:55 AM UTC

U1F984 wrote: post #12

ufo wrote: post #7

The author seems to complain about a lack of stack manip expressions like dup and rot, but at least for me that's what I would expect from an average programming language stack machine. Even Java, which does have those instructions, doesn't use them --- reuse happens via local variables. The way I see it, the difference between register and stack vms is all about the instruction encoding. Register VMs have fatter ins…

Java does use dup in some cases, e.g. public static void test() { new Object(); } 0: new #2 // class java/lang/Object 3: dup 4: invokespecial #1 // Method java/lang/Object." ":()V 7: pop 8: return

This `dup` seems entirely useless it actually supports the case for omitting it fron the instruction set.

Re: WASM is not quite a stack machine

#24

Post by bbkane » Tue, Apr 28, 2026, 11:57 AM UTC

shevy-java wrote: post #14

I am sad about WASM. It was a promise for epic greatness. It has failed to deliver that - so much is clear now. You rarely see any awesome success story shown with regard to WASM nowadays. What happened to the old promises? "Electron will be SUPER fast thanks to WASM" or "use any language, WASM unifies it all for the larger browser ecosystem". It feels as if WASM is on a step towards exctinction. Sure, it is mentione…

Looks like you're getting down voted, but the folks at Mozilla seem like they agree and are working towards making WASM more first class in the browser: https://hacks.mozilla.org/2026/02/making-webassembly-a-first...

Re: WASM is not quite a stack machine

#25

Post by ufo » Tue, Apr 28, 2026, 11:58 AM UTC

pjjpo wrote: post #13

ufo wrote: post #7

The author seems to complain about a lack of stack manip expressions like dup and rot, but at least for me that's what I would expect from an average programming language stack machine. Even Java, which does have those instructions, doesn't use them --- reuse happens via local variables. The way I see it, the difference between register and stack vms is all about the instruction encoding. Register VMs have fatter ins…

> Despite the name, register VMs also have a stack. Out of curiosity what do you think about this - in spite of the name, stack machines also have yet another stack. Ok I don't like that wording, but locals are basically the stack frames people know of from their computer arch class I think. It doesn't change the fact that Wasm operations have to have the execution stack as one or more of the operands. Seems like a s…

As you said, it's more like CPU stack frames. In a register VM all instructions can read and write to any position in the stack frame. In a stack VM, most instructions only read and write to the top but they are often combined with LOAD and STORE instructions, which can read and write to any position in the stack frame.

Re: WASM is not quite a stack machine

#26

Post by ronin_niron » Tue, Apr 28, 2026, 12:33 PM UTC

One thing nobody's named in the thread yet: WASM's validator is linear-time, single-pass, with no dataflow joins. That constraint is what gives the operand stack its weird shape. Every block, loop, and if carries a function-type signature. The operand stack at block entry has to match the parameter type, and at exit has to match the result type. Inside a block the validator only sees pushes and pops within that frame; it never has to merge stacks from sibling control-flow paths, because each path's exit type is independently checked against the same expected signature.

JVM went the other way: arbitrary control flow plus a verifier that does dataflow with type merges across joins. That's expensive enough that JVMs do it once at class load and cache the verified state. WASM specifically didn't want that bill; fast startup was a hard requirement.

So the prefix/postfix debate elsewhere in the thread is downstream of this. The encoded form is postfix because that's what trivially admits a linear validator; the textual LISP form is sugar for the same expression trees inside a typed frame. dup isn't missing for aesthetic reasons either: local.tee n followed by local.get n already gives you dup-equivalence through typed locals, and any stack op that didn't reduce to typed locals would either duplicate what locals already do, or break the validator's linearity guarantee.

Re: WASM is not quite a stack machine

#27

Post by layer8 » Tue, Apr 28, 2026, 12:37 PM UTC

asibahi wrote: post #23

U1F984 wrote: post #12

Earlier quoted context omitted.

Java does use dup in some cases, e.g. public static void test() { new Object(); } 0: new #2 // class java/lang/Object 3: dup 4: invokespecial #1 // Method java/lang/Object." ":()V 7: pop 8: return

This `dup` seems entirely useless it actually supports the case for omitting it fron the instruction set.

The only reason it is useless in this (arguably ill-chosen) example is because the result of “new Object()” is not used (hence the pop), which is an uncommon case. If test() instead returned the new object, or would use it in some other way after the initialization, then the dup would be needed. Invokespecial consumes the object reference on the stack, hence if you want to use it after invokespecial, you have to copy or duplicate it before.

Re: WASM is not quite a stack machine

#28

Post by keithwinstein » Tue, Apr 28, 2026, 12:39 PM UTC

asibahi wrote: post #11

I dont really disagree with the main premise of the article, which is that WASM is not really a stack language , but this part just gave me pause: > In textual Wasm, for example, they are instead represented in a LISP-like notation – not any less or more efficient The Text format, at least when it comes to instructions, it 1 to 1 with the binary format. The LISP-like syntax is mainly just syntax sugar[1]. ‘(’ plainin…

I can't speak to Binaryen, but afaik WABT's wat2wasm and wasm-tools's wat2wasm (aka wasm-tools parse) are both 100% spec-correct in this respect. Parsing the Wasm text format doesn't require any knowledge of the type of each instruction. If you have a counterexample would love to see it!

There are some cool edge cases if you want to print a mismatched multi-value instruction sequence in the folded form (which WABT and wasm-tools again handle "correctly," but not identically to each other, and not particularly meaningfully).

Re: WASM is not quite a stack machine

#29

Post by zozbot234 » Tue, Apr 28, 2026, 12:49 PM UTC

ronin_niron wrote: post #26

One thing nobody's named in the thread yet: WASM's validator is linear-time, single-pass, with no dataflow joins. That constraint is what gives the operand stack its weird shape. Every block, loop, and if carries a function-type signature. The operand stack at block entry has to match the parameter type, and at exit has to match the result type. Inside a block the validator only sees pushes and pops within that frame…

The whole point of having a type system is to endow program syntax with verifiable annotations that make validation easier. So if you wished to allow for otherwise "expensive" validation without overly impacting startup speed, the natural way of doing that is to extend the type system itself, in a way that offloads burden from the verifier to the producer. Arguably, this is exactly what WASM did when it implemented SSA phi-nodes via block return values and then extended those to multiple-value returns.

Re: WASM is not quite a stack machine

#30

Post by flohofwoe » Tue, Apr 28, 2026, 12:53 PM UTC

shevy-java wrote: post #14

I am sad about WASM. It was a promise for epic greatness. It has failed to deliver that - so much is clear now. You rarely see any awesome success story shown with regard to WASM nowadays. What happened to the old promises? "Electron will be SUPER fast thanks to WASM" or "use any language, WASM unifies it all for the larger browser ecosystem". It feels as if WASM is on a step towards exctinction. Sure, it is mentione…

The only failure of WASM is that it was overhyped beyond all reason. It's "just another" virtual instruction set, and for that it turned out pretty great. It's supported by Clang and by all browsers. That's already enough to make the whole idea work.

You don't hear much about it because for the people using it, web+wasm is "just another porting target", like Windows, macOS or Linux. WASM has become 'normal' and that's a good thing.

The main risk these days for WASM is feature creep, the spec is getting bloated with optional features (garbage collection etc...).