Write once, run everywhere.
I bet in few years we will run wasm natively on processor.
I bet in few years we will run wasm natively on processor.
The processes would have to translate the wasm into some form of register-based operations anyway, and a JIT compiler might be able to do this more efficiently since it can see a bigger picture than the processor.
Wasm is in this interesting spot where it's relatively low-level, but high-level enough to allow proper sandboxing. It strikes me that the arrangements to accommodate that, like call indirection via tables, could be optimized on CPU level. Not necessarily in a sense of a CPU that directly runs wasm, but rather a CPU architecture which is optimized to be a target for JIT or AOT compilers from wasm.
It looks like Gary Bernhardt was pretty spot on in his talk "The Birth and Death of JavaScript": (https://www.destroyallsoftware.com/talks/the-birth-and-death...)
Instruction caches (and JITs to a degree) solve the same problem in much more general ways. That's why Azul went out of their way to create an appliance to run Java code with custom CPUs, and ended up with a pretty standard RISC for the most part.
All of that applies to WASM machines too.
In contrast, WebAssembly would be a terrible project to implement directly in logic; there are no relative offsets so incrementing an instruct pointer register simply doesn't work, which hardware is very good at. fn calls are referred to by name indexed into a table at the bytecode level, so you're inherently dealing with a level of indirection that would require 'flattening' or inlining the table values to work around before being executed, or, alternatively, you'd have to just bite the bullet and put limits on their size, and eat the cost of the indirection. Similarly, CFG blocks in WASM are represented as literal scoped blocks with nested instructions at the syntax level -- not simple jumps/calls. You need to extract the back/forward edges from the CFG to recover that information and translate it to direct jump operations.
At this point, you are just implementing a compiler, and if you choose to do it in hardware, you are willingly trying to shoot yourself in the foot (or the face), and it will end badly. You're far better off calling a spade a spade and compiling, in software, to a representation that actually can be implemented efficiently in hardware. But you could of course hide this compiler in the firmware to make it "seem" like WebAssembly is the native ISA, and the small surface area of the specification can help ensure you do it safely and correctly. This is probably for the best anyway, because it's dramatically harder to design correct hardware vs correct software.