lua-users home
lua-l archive

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


Adam D. Moss wrote:
> Ah, does this imply that the legendary LuaJIT is a modification
> of the stock Lua distribution?  I'd assumed that it was so
> invasive that there'd be no chance of mix-and-matching with
> other Lua patches.  I'm glad that it sounds more like 'patchset'
> than 'fork'.

Well apart from the (otherwise pretty orthogonal) RVM patchset,
the diff to standard Lua boils down to around 50 lines. Most of
it is making a few internal functions accessible outside of
their source files. A few structures need new members and
initializers, too. The real glue to the JIT engine is just two
small changes in ldo.c.

Ok, I did change the standalone to add some options (-j on,
-j off and so on). But this is outside the core and not required.

All of the real stuff is in extra (new) source files. Combining
it with your own changes to the core shouldn't be too difficult
(the RVM patchset is a different story, though).

Note that I'm only targeting x86 with lua_Number = double for the
first release (but everything is set up for multi-arch support).

Right now I'm trying to move all optional stuff out of the
C code and into Lua files by making the JIT engine pluggable.
That should make it even simpler and smaller.

E.g. luajit -l jit.dump -e 'print "foo"' will disassemble the
machine code and mix it with the bytecode by intercepting
the compiler frontend/backend. Nice for debugging, but no point
in keeping this in the core. Yes, jit.dump is a Lua module. :-)

Ok, before it really gets 'legendary', I'll better keep quiet
and work on it (that ci->tailcall counter _is_ annoying).