3 ms·

I'm hoping someone brings WASM to MCUs with a HAL interface like WASI does for OS platform functionality. As far as I can tell, the byte code is simple and easy

I'm hoping someone brings WASM to MCUs with a HAL interface like WASI does for OS platform functionality. As far as I can tell, the byte code is simple and easy to write an interpreter for, with a lot of practically useful features like static memory blocks declared ahead of time that make it conducive to MCUs. It should even be possible to write test harnesses with simulators for each architecture that gives a precise prediction for how many cycles a given block of WASM will take in an interpreter so that timing for interrupt handlers, tasks, etc can all be worked out in simulation without even touching the hardware. If a given block of WASM isn't performant enough in the interpreter, then drop it to compiled code and expose it to the rest of the WASM - at least then only a small fraction of your code requires a painful firmware upgrade, the rest can be updated in a user defined section of ROM. It would be great to have a compiler/linker combo that could use annotations to configure which parts of the firmware should be compiled and which should be interpreted. With inlining or even just AST substitution (replace global vars with register access), it should provide all of the low level access necessary while still allowing for high level Arduiono style libraries

nneonneo 5y ago
Having messed with some WASM code, I would say that the byte code is NOT easy to write an interpreter for due to the (IMO insane) way blocks work. Blocks are nested but the start/end tags need to be matched up in order to determine where control flow goes - unlike jump instructions, the block tags don’t come with offsets built in. This means a fully-fledged interpreter needs to maintain a stack of blocks and (for efficiency) pre-scan each function to identify the block boundaries. That’s going to hurt performance a lot and take up valuable memory on a microcontroller. A modified WASM with explicit jumps and less “magic” behavior would be great. Perhaps a transpiler could generate such a “interpreter-friendly” pseudo-WASM to be loaded on the microcontroller. (FWIW, even though WASM supports static data blocks, it also has provisions for dynamic allocation, and most WASM programs over-allocate their static blocks to make room for a C stack. So, in practice, making WASM work for microcontrollers and static data would also mean new languages or compilers that are much more conservative with memory use.)
- zozbot234 5y ago
  The blocks-with-return-values WASM uses are quite conducive to static analysis, so it's a rather sensible choice for a general purpose VM. It's essentially a different form of SSA which dispenses with the unintuitive phi-function syntax. Obviously, for actual execution, one might want a lightweight pre-processing step introducing actual jump targets.
- sound_and_form 5y ago
  Having written an interpreter for Wasm (Wasm3), you're right, it's not an ideal format for direct interpretation. Wasm3 does a transcoding pass first to optimize for speed, but we still have it running on some pretty constrained devices.

nneonneo 5y ago

Having messed with some WASM code, I would say that the byte code is NOT easy to write an interpreter for due to the (IMO insane) way blocks work. Blocks are nested but the start/end tags need to be matched up in order to determine where control flow goes - unlike jump instructions, the block tags don’t come with offsets built in. This means a fully-fledged interpreter needs to maintain a stack of blocks and (for efficiency) pre-scan each function to identify the block boundaries. That’s going to hurt performance a lot and take up valuable memory on a microcontroller. A modified WASM with explicit jumps and less “magic” behavior would be great. Perhaps a transpiler could generate such a “interpreter-friendly” pseudo-WASM to be loaded on the microcontroller. (FWIW, even though WASM supports static data blocks, it also has provisions for dynamic allocation, and most WASM programs over-allocate their static blocks to make room for a C stack. So, in practice, making WASM work for microcontrollers and static data would also mean new languages or compilers that are much more conservative with memory use.)

zozbot234 5y ago
The blocks-with-return-values WASM uses are quite conducive to static analysis, so it's a rather sensible choice for a general purpose VM. It's essentially a different form of SSA which dispenses with the unintuitive phi-function syntax. Obviously, for actual execution, one might want a lightweight pre-processing step introducing actual jump targets.
sound_and_form 5y ago
Having written an interpreter for Wasm (Wasm3), you're right, it's not an ideal format for direct interpretation. Wasm3 does a transcoding pass first to optimize for speed, but we still have it running on some pretty constrained devices.