I've used it to translate SQLite (with a few extensions) and, that I know of, it's been used (to varying degrees of success) to translate the MARISA trie library (C++), libghostty (Zig), zlib, Perl, and QuickJS.
More on-topic, I use a mix of an unevaluated expression stack and a stack-to-locals approach to translate Wasm.
Edit: Yep. In article referenced from the original: http://troubles.md/posts/wasm-is-not-a-stack-machine/
Double edit: Some of this has already been fixed in WASM: https://github.com/WebAssembly/multi-value
Very well articulated and concise critique by somebody who seems to have a great amount of knowledge and experience with the topics.
The way I see it, the difference between register and stack vms is all about the instruction encoding. Register VMs have fatter instructions in exchange for needing fewer LOAD and STORE operations. Despite the name, register VMs also have a stack.
public static void test() {
new Object();
}
0: new #2 // class java/lang/Object
3: dup
4: invokespecial #1 // Method java/lang/Object."<init>":()V
7: pop
8: returnOut 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 stack machines to me too, though I don't know more details on why the specific design of Wasm would make optimizing compilers harder to write than JVM as the article suggests (I think?).
> 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].
‘(’ plaininstr instrs ‘)’ ≡ instrs plaininstr
Unfortunately, in my limited testing, tools like `wat2wasm` and Binaryen's `wasm-as` don't seem to adhere to (my perhaps faulty understanding of) the spec, and demand all instructions in a folded block be folded and have the "correct" amount of arguments, which makes Binaryen do weird things like
(return
(tuple.make ;; Binaryen only pseudoinstruction
(local.get 0) ;; or w/e expression
(local.get 1) ;; or w/e expression
)
)
local.get 0
local.get 1
return
Edit: An example that is easily done with the stack syntax and not with lisp syntax is the following:
call function_that_returns_multivalue
local.set 2 ;; last return
local.set 1 ;;
local.set 0 ;; first return
(local.set 0
(local.set 1
(local.set 2
(call function_that_returns_multivalue
( ;; whatever input paramters
)))))
[1]: https://webassembly.github.io/spec/core/text/instructions.ht...
https://raw.githubusercontent.com/soegaard/webracket/refs/he...
As a small example, here is a definition of `$car` which extracts the first value from a pair.
(func $car (type $Prim1)
(param $v (ref eq))
(result (ref eq))
(if (result (ref eq))
(ref.test (ref $Pair) (local.get $v))
(then (struct.get $Pair $a (ref.cast (ref $Pair) (local.get $v))))
(else (call $raise-pair-expected (local.get $v))
(unreachable))))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 foundational than the other -- all notations can encode all expression trees, and postfix and prefix notations in particular have the same coding efficiency.
So sure, the LISP syntax is sugar, but for what? It's not sugar for a stack program, because prefix notation in general can't represent an arbitrary stack program; it's sugar for a mathematical expression. Which is encoded in postfix notation in binary, sure, but that's just an implementation detail, and prefix notation could've been selected when Wasm was born with little adversarial consequences.
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.
It is explicity sugar for the stack operations, per my reading of the spec.
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 mentioned, it is used, but let's be honest - only few people really use it. And that won't change either.
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.