[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: LuaJIT 2 and the creation of object files/executables
- From: Mike Pall <mikelu-0911@...>
- Date: Tue, 3 Nov 2009 11:16:57 +0100
Joshua Jensen wrote:
> For consoles such as Xbox 360, it is not possible to emit instructions
> on the fly and pass certification to ship the game.
Yep, same thing for PS3. If MS/Sony ever want to get JIT compilers
running on their platform they gotta come up with a solution.
> Ignoring the fact
> that the Xbox 360 is PowerPC-based and therefore incompatible with
> LuaJIT in its current form, could the code generator be tailored to
> generate a linkable .obj file with a translation of the Lua code to
> native instructions?
Not easy. The emitted machine code contains runtime values of all
sorts. Relocations to helper functions are probably easy. But
heap-allocated objects get their addresses at runtime. You'd need to
add all sorts of indirections and a special loader.
Also, the trace compiler comes up with a different set of traces,
depending on runtime behavior. It would be hard to ensure you get
sufficient coverage of the relevant code paths. Some user, somewhere
in the world will slash the wrong monster and then you'd be stuck
with the interpreter for some important code paths (this may or may
not be ok). Turning a JIT compiler into a full coverage compiler is
not an easy undertaking.
A more realistic option for the near future would be to port just
the LJ2 interpreter to PPC. PPC has a good FPU, little variation
in instruction support and should cope well with the overall
design of the VM. It would be much easier than an ARM port.
Getting a 3x speedup over Lua wouldn't be too bad, initially?
> For LuaJIT in its current form, is it a possibility to generate a
> linkable x86 .obj file or an executable from a Lua script? I have used
> Lua heavily within a build system, with Lua scripts (often the same)
> being called hundreds of times from different build processes. Having a
> native x86 version of the script could save a great deal of time over
> hundreds of invocations.
Compile time is negligible. We are talking about microseconds up
to milliseconds here. And it's done incrementally during the
execution, so there are no big pauses either.