Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

WASM is not quite a stack machine

purplesyringa.moe

Post reply on HN
Print view View original

31–40 of 47 posts

Re: WASM is not quite a stack machine

#31

Post by flohofwoe »

bbkane wrote: post #24
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...

That's specifically about string-marshalling overhead, which is only a problem when trying to talk to the DOM from the WASM side (which arguably is a silly idea to begin with, but to each their own I guess).

Re: WASM is not quite a stack machine

#32

Post by Validark »

I like to read assembly a lot, and I don't really see the point in WASM trying to be a stack machine. None of our computers are stack machines.

Not to mention that compiler backends are missing tons of optimizations even on mainstream targets on real hardware, I just don't think WASM makes sense economically. They should have just picked RISC-V and called it a day.

Re: WASM is not quite a stack machine

#33

Post by asibahi »

keithwinstein wrote: post #28
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 an…

This is the wat2wasm tool I have been playing with: https://webassembly.github.io/wabt/demo/wat2wasm/

It refuses to accept the following

    (module
      (func (export "addTwo") (param i32 i32) (result i32)
        (i32.add 
          local.get 0
          local.get 1
        )
      )
    )
which based on my reading should be accepted.

I will try the tools you mentioned but I personally settled on generating the unfolded ones for my experiments as they just seem easier.

Re: WASM is not quite a stack machine

#34

Post by wabstractions »

Calling Wasm a stack machine is misleading.

It’s closer to a structured IR that uses a stack encoding, not a machine where the stack is the primary state. The absence of real stack operations (dup, swap, etc.) is not accidental — it shows the stack isn’t meant to be observable.

If you build even a tiny real stack CPU (simulator + assembler + traces), the difference becomes obvious very quickly: the stack stops being syntax and starts being semantics.

So the real question isn’t “is Wasm a stack machine?” but “why does it avoid being one?”

My take: because it’s designed for validation and compilation, not execution as a first-class machine model.

And that’s fine — but then we should call it what it is.

Re: WASM is not quite a stack machine

#35

Post by gzread »

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…

Why would you write in C++ then wrap it in a C++ to JavaScript wrapper then wrap it in a JavaScript to C++ wrapper

Re: WASM is not quite a stack machine

#36

Post by lioeters »

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…

You're just feeling the "trough of disillusionment", after the initial hype of the technology wears off and reality sets in. If you pay attention and actually look at what it's being used for, it's clear that Wasm has been very successful and will be around for decades. It's not perfect, it has problems both solvable and not, but it is well-designed as a solid foundation and its usage is growing year after year. Let's be honest - you don't know what you don't know, and making grandiose statements backed up by no experience or understanding is worse than useless. I suggest you learn about the thing, if you're interested in what's good about it.

Re: WASM is not quite a stack machine

#37

Post by rogerbinns »

stevefan1999 wrote: post #2

I'm trying to implement a WASM to C compiler, and because of that not-quite-so-stack behavior, I can actually guarantee that it will always build an expression and I don't have to discard or reset stack value! Everything stays within that function, which is very neat, and I think it is one of the reason WAT, the textual format is so neat, that you can represent it with a S-Expression.

Check out wastrel https://codeberg.org/andywingo/wastrel

Of note WASM 3 has garbage collection (GC), multi-memory, exception handling, tail calls and more which can be challenging to implement.

Re: WASM is not quite a stack machine

#38

Post by [deleted] »

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…

[deleted]

Re: WASM is not quite a stack machine

#39

Post by Weebs »

flohofwoe wrote: post #30
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'…

I like to think about it as a VM that all the major browsers agreed to implement, designed by a broad group of stake holders with lessons from past plugin and VM systems

For that it's pretty cool. I still wish we had DOM access though

Re: WASM is not quite a stack machine

#40

Post by ronin_niron »

zozbot234 wrote: post #29
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 S…

Yes, this generalizes well. The same producer-side annotation pattern shows up in every type-system extension WASM has shipped: typed function references encode signatures into the reference type, so indirect calls through them don't need runtime signature dispatch; the GC proposal uses declared subtyping via explicit (sub $X $Y) clauses, so subtype checks are chain walks instead of structural equivalence; exception handling uses nominal tag identity, so try/catch dispatch matches by name instead of structurally.

Each extension grows the type system and the producer's job, and the verifier stays linear. JVM made the equivalent move retroactively when StackMapTable became mandatory in Java 7, explicit type annotations at branch targets so the verifier doesn't compute joins via fixpoint. WASM was designed with that lesson built in from day one.

Post reply on HN