WASM byte code is structured into a tree, which means an interpreter loop wouldn't perform well. You'd really want to flatten it into a simpler bytecode before interpreting it -- and you'd want to do other transforms on it before optimizing it.

I don't think WASM bytecode is a good format for execution, and it's only mediocre as a compilation target.

Then why not abandon wasm, and make this byte code a target for llvm?

LLVM bitcode is CPU and ABI dependent, and isn't even stable between LLVM releases.

Bad question on my part. More relevant: Why wasm? From what I gather, js seems to already have a bytecode for their JIT runtime. Why not expose that so that we can have C++ in the web?

> js seems to already have a bytecode for their JIT runtime

This is kind of a nonsensical statement. JS itself doesn't have a bytecode, it's just a specification of the language you write scripts in.

Each implementation has its own intermediate representations, including bytecode formats.

WASM is a vendor-neutral standard that is designed as a compilation target and designed with safety in mind.

SpiderMonkey/JSC/V8 internal bytecode formats are just that, compiler internals.

I asked the same question, see below for interesting thread

This isn’t a standard.

They are different.

Unifying is not a bad idea.