3 ms·

I've certainly thought about it :) If you can write an interpreter, then you can implement it in hardware. Whether it will be _efficient_ compared to using an

I've certainly thought about it :) If you can write an interpreter, then you can implement it in hardware. Whether it will be _efficient_ compared to using another ISA is a different matter. Of the top of my head: the unbounded block stack would need to be managed and spilled to memory as it grows (not unlike SPARC's register windows), manageable but complex. The operand stack either needs to be bounded or likewise spilled to memory. For a superscalar, the WASM bytecodes aren't the nicest to decode, but neither are x86 nor RISC-V (C implies variable length instructions). Unsurprisingly, it would make a lot more sense to design a µArch that is well matched (eg. has rotation instruction) to WASM and for which translation is fairly straightforward. I'm excited about WASM exactly because it provides an interesting path for getting software on new and exciting uArchs. It's _MUCH_ less work to make a WASM translator than to do the full software stack.

titzer 3y ago
With a pre-pass on the bytecode (e.g. during verification), one can compute a side data-structure that makes it possible to interpret Wasm without tracking the control stack dynamically. It works surprisingly well.
- FullyFunctional 3y ago
  The OP asked about a WASM-cpu. It assume he meant that literally thus without preprocessing. Once you allow preprocessing there's no limited to what you can do and in fact you can do something really efficient (margin is too narrow to contain the full proof).
  - titzer 3y ago
    I know, but the safety guarantees of Wasm are established by validating the code first. The sidetable that Wizard's interpreter used is small enough (about 1/3 the side of the original code) it could fit in a hardware cache along-side the original code, kind of like a u-op cache. Wizard computes this sidetable during code validation, so there is no separate step. This is the paper I wrote about it: https://dl.acm.org/doi/abs/10.1145/3563311 https://dl.acm.org/doi/abs/10.1145/3563311 I think the technique could be adapted to make a Wasm CPU, but the issues mentioned (e.g. variable-length instructions) would complicate the CPU frontend. I think it being stack-based isn't as much of an issue, as register-renaming will virtualize the Wasm operand stack. But given how complex modern CPUs are, it'd be hard to build a competitive super-scalar chip (really for any ISA) without some verious serious investment.
    - FullyFunctional 3y ago
      Thanks for the paper. > it'd be hard to build a competitive super-scalar chip (really for any ISA) without some verious[sic] serious investment "Hundreds of millions of dollars" cf. Mark Horowitz's Micro 35 keynote (https://www.youtube.com/watch?v=q8WK63joI_Y&t=1140s https://www.youtube.com/watch?v=q8WK63joI_Y&t=1140s) but if you look at the stack in his graph, it's obvious that the architecture portion of this is tiny. Making a superscalar core simulation (= "model"), or even an FPGA softcore, is within the reach of any sufficiently motivated individual and indeed there are several already. Of course the performance will be dramatically lower than a state of the art silicon implementation.

titzer 3y ago

With a pre-pass on the bytecode (e.g. during verification), one can compute a side data-structure that makes it possible to interpret Wasm without tracking the control stack dynamically. It works surprisingly well.

FullyFunctional 3y ago
The OP asked about a WASM-cpu. It assume he meant that literally thus without preprocessing. Once you allow preprocessing there's no limited to what you can do and in fact you can do something really efficient (margin is too narrow to contain the full proof).
- titzer 3y ago
  I know, but the safety guarantees of Wasm are established by validating the code first. The sidetable that Wizard's interpreter used is small enough (about 1/3 the side of the original code) it could fit in a hardware cache along-side the original code, kind of like a u-op cache. Wizard computes this sidetable during code validation, so there is no separate step. This is the paper I wrote about it: https://dl.acm.org/doi/abs/10.1145/3563311 https://dl.acm.org/doi/abs/10.1145/3563311 I think the technique could be adapted to make a Wasm CPU, but the issues mentioned (e.g. variable-length instructions) would complicate the CPU frontend. I think it being stack-based isn't as much of an issue, as register-renaming will virtualize the Wasm operand stack. But given how complex modern CPUs are, it'd be hard to build a competitive super-scalar chip (really for any ISA) without some verious serious investment.
  - FullyFunctional 3y ago
    Thanks for the paper. > it'd be hard to build a competitive super-scalar chip (really for any ISA) without some verious[sic] serious investment "Hundreds of millions of dollars" cf. Mark Horowitz's Micro 35 keynote (https://www.youtube.com/watch?v=q8WK63joI_Y&t=1140s https://www.youtube.com/watch?v=q8WK63joI_Y&t=1140s) but if you look at the stack in his graph, it's obvious that the architecture portion of this is tiny. Making a superscalar core simulation (= "model"), or even an FPGA softcore, is within the reach of any sufficiently motivated individual and indeed there are several already. Of course the performance will be dramatically lower than a state of the art silicon implementation.