3 ms·
I've been working on a hand written Lua interpreter in WASM (using Lua as a macro assembler, ofc). Long term I'd like to have it jit wasm code: https://github.c
by __s 9y ago
I've been working on a hand written Lua interpreter in WASM (using Lua as a macro assembler, ofc). Long term I'd like to have it jit wasm code: https://github.com/serprex/luwa https://github.com/serprex/luwa
Currently in the process of porting the parser & codegen that's implemented in Javascript to Lua so that I can have the implementation bootstrap itself. Plus the codegen was for a bytecode I came up with in JS but which has evolved quite a bit since getting everything in place to happen in WASM
- sitkack 9y agoThis is super cool. It looks like you are in the process of porting the .js to .lua? Wasm will exist in many more places than Js will. I think I would have started with many of the Lua on Js implementations and used zero Js. Have you seen http://stefan-marr.de/2015/10/jit-data-structures-fully-reflective-vms-and-meta-circular-meta-tracing/ http://stefan-marr.de/2015/10/jit-data-structures-fully-refl... Check out this paper, https://www.cs.purdue.edu/homes/rompf/papers/amin-draft2017a.pdf https://www.cs.purdue.edu/homes/rompf/papers/amin-draft2017a... Collapsing Towers of Interpreters
- __s 9y agoYes: at the end there should only be the light rt.js layer. Manipulating DOM is not in my scope; WASM is evolving on that front still. Currently rt.js has to expose a free method for handles, that may become unnecessary as WASM's gc capabilities develop Thanks for the links