3 ms·
I mean, you don't even have to go as far as register allocation to see the problems that make it all a big dead end. WebAssembly requires e.g. the call opcode p
by aseipp 5y ago
I mean, you don't even have to go as far as register allocation to see the problems that make it all a big dead end. WebAssembly requires e.g. the call opcode parameter to actually be an index into the global function table, causing an indirection, which is about a trillion times worse than current CPUs which can just directly write the new PC to the register file at once. The spec is littered with stuff like this, for good reason.
Considering WebAssembly is designed to be relatively easy to compile ahead of time, there's no reason to make the hardware worse when you could just ship "firmware" that compiles to an underlying ISA transparently, and reuse decades of existing knowledge. This would make the system behave more like the AS/400 and IBM iSeries, which abstracted away the underlying microarchitecture through its firmware.
- AstralStorm 5y agoTechnically there are a few extra tricks you could pull off in microcode if you natively support the instruction set, that even a sufficiently smart JIT compiler cannot. It would be similar to what ARM tried with Jazelle way back when, with some very modest performance gain at best. Not worth the time.
- nneonneo 5y agoAnd, if you want to literally run the bytecode, there’s that little issue of nested blocks and block start/end tags…a proper WASM CPU would have to perform parsing in order to handle any form of control flow. (Alternatively, you could load not-quite-WASM that’s been gently preprocessed to use normal jumps, but at that point why not just go all the way and generate native code for a real CPU?)