Replace native LuaJIT bytecode compiler?

[lukego]

I'm really happy to discover this cool project!

Has anybody looked into "dropping in" this bytecode compiler to replace the C implementation in LuaJIT? This is something we have been discussing over at raptorjit/raptorjit#248 but we weren't aware of this project until now.

[franko]

Hi,

as far as I know, no, nobody did the drop in you are talking about.

To me it make some sense and it should be feasible without big difficulties. You could have then a luajitvm that only run the bytecode and a luajit-frontend written in Lua that does the parsing if required and invokes luajitvm appropriately.

I would say that the only technical things that should be done on the luajit lang toolkit is to fix its bytecode generation so that it always generate identical bytecode to what luajit does. Currently this is mostly true except for conditional expression like

local a = expr1 and expr2 or expr3

Generating identical bytecode is desirable to be sure that no bugs are introduced from the language toolkit side.

To this purpose the language toolkit has extensive tests that compares the bytecode byte-by-byte but currently they are not required to match.

[franko]

Oh, I forgot to add that support for 2.1 bytecode should be added. Currently only 2.0 is supported.

[fsfod]

One changes needed for 2.1 bytecode is calls on GC64 builds need an extra stack slot for the two slot call frames.

[gotzmann]

Oh, I forgot to add that support for 2.1 bytecode should be added. Currently only 2.0 is supported.

Are there plans for 2.1 support in this toolkit ?