5 ms·

Write once, run everywhere. I bet in few years we will run wasm natively on processor.

giancarlostoro 7y ago
Didn't Apple do some CPU that runs JavaScript in a more optimized fashion? It wouldn't surprise me, which is odd cause for years I heard that was the plan for Java, but regular processors got faster and faster and the VM stayed.
- grenoire 7y ago
  There have been ARM chips with added instructions for faster JavaScript processing due to some very odd and non-standard behaviour for common operations. See https://stackoverflow.com/questions/50966676/why-do-arm-chips-have-an-instruction-with-javascript-in-the-name-fjcvtzs https://stackoverflow.com/questions/50966676/why-do-arm-chip... for more deets.
oefrha 7y ago
https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death...
kevingadd 7y ago
WASM is poorly designed for execution directly in-silicon. It's not that kind of IR. You'd lower it into some other representation no matter what, so why not x86 or ARM? The hardware already exists and the development tools exist too.
- sitkack 7y ago
  The instructions in your binaries aren't directly executed either, they get lowered into uOps.
  - aseipp 7y ago
    That's not really relevant to the suitability of WASM in hardware, though. uops are an implementation detail of microarchitectures; even if you do not introduce the uop design into your architecture, x86, ARM, etc ISAs are still efficient to implement in logic for a number of reasons. For example, instructions in a traditional ISA normally encode things like the register operands they reference as part of encoded instruction. The bits corresponding to the register operands are carefully designed to index into another piece of memory, the register file. This means decoding the operands from an instruction and referencing the relevant registers is extremely cheap in hardware, because you simply slice a few bits out of an existing wire and do a lookup/relative increment/whatever. Similarly, things like relative jumps are encoded directly as offsets that get added to an instruction pointer, which again is extremely cheap. 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.
thesuperbigfrog 7y ago
WASM machines--the next (hopefully) better version of Lisp machines (https://en.wikipedia.org/wiki/Lisp_machine https://en.wikipedia.org/wiki/Lisp_machine)! 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-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death...)
- monocasa 7y ago
  Lisp machines didn't go away because of some conspiracy, they just stopped making sense. The vast majority of the benefit was that since they ran on (and were compared to other) 1980s minicomputer hardware without instruction caches, pulling the interpreter into microcode meant that the interpreter's overhead wasn't competing with data fetches on the von Neumann memory bus. 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.
GlitchMr 7y ago
I don't think that will happen. The design of WebAssembly (in particular not having GOTOs) isn't really hardware-implementation friendly. I would rather expect hardware JVM or BPF implementation than WASM.
goto11 7y ago
This was also attempted for Java bytecode but didn't really pan out. I think the benefit just wasn't there compared to JIT compiling for a regular 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.
- int_19h 7y ago
  JVM bytecode is very high-level though (it deals with objects, and has opcodes for method calls etc). 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.
  - marcthe12 7y ago
    I wonder it's small enough to have the interpreter in kernel space
Sharlin 7y ago
Just like we these days run JVM bytecode natively on processors.
Ididntdothis 7y ago
I know. And we all use Java native CPUs right now.

Didn't Apple do some CPU that runs JavaScript in a more optimized fashion? It wouldn't surprise me, which is odd cause for years I heard that was the plan for Java, but regular processors got faster and faster and the VM stayed.

grenoire 7y ago
There have been ARM chips with added instructions for faster JavaScript processing due to some very odd and non-standard behaviour for common operations. See https://stackoverflow.com/questions/50966676/why-do-arm-chips-have-an-instruction-with-javascript-in-the-name-fjcvtzs https://stackoverflow.com/questions/50966676/why-do-arm-chip... for more deets.

oefrha 7y ago

https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death...

kevingadd 7y ago

WASM is poorly designed for execution directly in-silicon. It's not that kind of IR. You'd lower it into some other representation no matter what, so why not x86 or ARM? The hardware already exists and the development tools exist too.

sitkack 7y ago
The instructions in your binaries aren't directly executed either, they get lowered into uOps.
- aseipp 7y ago
  That's not really relevant to the suitability of WASM in hardware, though. uops are an implementation detail of microarchitectures; even if you do not introduce the uop design into your architecture, x86, ARM, etc ISAs are still efficient to implement in logic for a number of reasons. For example, instructions in a traditional ISA normally encode things like the register operands they reference as part of encoded instruction. The bits corresponding to the register operands are carefully designed to index into another piece of memory, the register file. This means decoding the operands from an instruction and referencing the relevant registers is extremely cheap in hardware, because you simply slice a few bits out of an existing wire and do a lookup/relative increment/whatever. Similarly, things like relative jumps are encoded directly as offsets that get added to an instruction pointer, which again is extremely cheap. 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.

thesuperbigfrog 7y ago

WASM machines--the next (hopefully) better version of Lisp machines (https://en.wikipedia.org/wiki/Lisp_machine https://en.wikipedia.org/wiki/Lisp_machine)! 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-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death...)

monocasa 7y ago
Lisp machines didn't go away because of some conspiracy, they just stopped making sense. The vast majority of the benefit was that since they ran on (and were compared to other) 1980s minicomputer hardware without instruction caches, pulling the interpreter into microcode meant that the interpreter's overhead wasn't competing with data fetches on the von Neumann memory bus. 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.

GlitchMr 7y ago

I don't think that will happen. The design of WebAssembly (in particular not having GOTOs) isn't really hardware-implementation friendly. I would rather expect hardware JVM or BPF implementation than WASM.

goto11 7y ago

This was also attempted for Java bytecode but didn't really pan out. I think the benefit just wasn't there compared to JIT compiling for a regular 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.

int_19h 7y ago
JVM bytecode is very high-level though (it deals with objects, and has opcodes for method calls etc). 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.
- marcthe12 7y ago
  I wonder it's small enough to have the interpreter in kernel space

Sharlin 7y ago

Just like we these days run JVM bytecode natively on processors.

Ididntdothis 7y ago

I know. And we all use Java native CPUs right now.