lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

>However, I stuck to the public Lua C APIs, so the resulting code ended
>slower than the stock interpreter.

Lua-AOT uses the internal Lua APIs, and therefore only works with a modified version of Lua VM that exposes these APIs. It implements each VM instruction using code that is essentially copy pasted from lvm.c.

One consequence of this is that at runtime the compiled functions in Lua-AOT are also represented as "Lua closures" instead of "C closures", as would be done in something that uses the regular C API.

One related work that I can think of right now would be Gabriel Ligneuls bytecode to LLVM compiler

Another would be the Lua Vermelha JIT

The main difference in Lua-AOT's case is that it is very simple, since it is basically just copy pasting the regular interpreter code. This makes it less suitable as a production tool, but also means it's easy to experiment with the implementation.
>Both projects hit limitations with coroutines, upvalues and tail calls.
>Do any
>of these three limitations apply to lua-aot?

Since Lua-AOT is abusing the internal APIs and uses the same code as the regular Lua interpreter, these features are not a problem.

Tail calls and upvalues should work right now. Coroutines are not implemented yet, but it should be possible to make them work without much effort.

>As for compatibility: did you try to run the Lua test suite with
>If so, how much of it can it handle?

I haven't tested that test suite yet. But now that you mention it, it would probably be a good idea to do so!

-- Hugo