I've got a Befunge JIT compiling directly to WASM: https://github.com/serprex/Befunge/tree/master/js https://github.com/serprex/Befunge/tree/master/js (hosted:

I've got a Befunge JIT compiling directly to WASM: https://github.com/serprex/Befunge/tree/master/js https://github.com/serprex/Befunge/tree/master/js (hosted: http://etg.dek.im/funge/funge.html http://etg.dek.im/funge/funge.html ) Maybe I should move on to something a little more practical Note that there seems a lot of misinterpretation of WASM as a good VM bytecode target. You're stuck with i32/i64/f32/f64. Strings have to be manually managed through byte indexing. There's no GC. Targeting WASM directly is really close to targeting an actual ISA directly. So efficient implementation to WASM is going to come off closer to something like LuaJIT. It also doesn't facillitate self modifying code so lazily compiling will imply either using a trampoline to jump between multiple WASM modules or recompiling everything There's no jump instruction in WASM, so arbitrary goto has to be converted into loop-and-switch. The Befunge VM I linked breaks that down to only relooping between basic blocks. Browsers optimize that pattern. There's room to play around & see if they can optimize something like a CPS VM. Instead of dispatching based on the value of a memory cell, encode an instruction as a 'store-next-instruction to local, break to instruction implementation (if not short bytecode), have that instruction end by looping back, where we switch to next instruction which repeats the store-next-instruction to local'. Where next-instruction encodes this dance repeatedly. Hot areas of the VM may then be inlined by the browser's JIT To summarize the above paragraph: instead of compiling to bytecode, compile to threaded gotos