On Wed, Jun 22, 2011 at 19:51, Josh Haberman<jhaberman@gmail.com> wrote:
HyperHacker<hyperhacker<at> gmail.com> writes:
I was just wondering to myself if LuaJIT could ever be hacked to
function as a Lua compiler, that compiles scripts to standalone
executables or libraries.
By "standalone executable" do you mean:
1. one that embeds the LuaJIT and the Lua program, or
2. one that contains machine code for the original Lua program,
but not LuaJIT or Lua program itself.
(1) is not very difficult.
(2) is not feasible, AIUI. LuaJIT can only generate fast code
when it can observe runtime traces. These traces are not
something that can be generated ahead-of-time, because they
depend on eg. the actual types of variables. Even if they could
be generated ahead-of-time, the runtime profile of the program
could change as it is running; a tracing JIT can adapt to this,
but AOT compiling could not, which would compromise performance.
Also, since the slow paths of the JIT-ted code fall back to
the interpreter, you'd have to include LuaJIT's interpreter in
the standalone executable.
Josh
I hadn't thought of the idea of just statically linking Lua and LuaJIT
into a program, but that's probably a better and more feasible
approach to making standalone executables than trying to compile to
native code. What I was more interested in though was the possibility
of writing a Lua module, which uses the FFI to do things that normally
would require dropping down to C (typically bindings to C libraries),
and being able to compile it into a shared object file that could then
be loaded and used by Lua without LuaJIT.
Doing so by including LuaJIT in the module is still an interesting
idea, but means your module will be rather large, and wastes space if
you have more than one and/or you're using LuaJIT anyway.
By the sounds of it, LuaJIT itself can't feasibly compile to native
code, but I'm still curious about the possibility of writing bindings
to C libraries entirely in Lua, without depending on LuaJIT for the
FFI.
--
Sent from my toaster.
