3 ms·
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 ne
by 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 agoThe 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 agoHaving 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.