3 ms·

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 x8

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.

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.