3 ms·

This could be be very useful for me. Long term, I would love to see a Lua to WASM compiler/transpiler with additional Lua runtime functionality efficiently imp

by jshmrsn 10y ago

This could be be very useful for me. Long term, I would love to see a Lua to WASM compiler/transpiler with additional Lua runtime functionality efficiently implemented in WASM as well. Since WASM already has its own stack-based VM, why not skipthe additional Lua VM bytecode execution layer? I would love to work on this myself, but right now the time investment isn't practical for me.

__s 10y ago
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
6nf 10y ago
Lua compiles to C which compiles to WASM, and the Lua forums already has some people demonstrating Lua code compiled to WASM like this. So you can do this already to some extent.

by jshmrsn 10y ago

__s 10y ago

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

6nf 10y ago

Lua compiles to C which compiles to WASM, and the Lua forums already has some people demonstrating Lua code compiled to WASM like this. So you can do this already to some extent.