Re: LuaJIT roadmap 2008

[Mike Pall <mikelu-0802@...>]

Mark Hamburg wrote:
> Any chance that there would be a release without the JIT but with the
> re-designed VM?

Right now the whole VM is still a moving target (I've changed
several bytecodes just yesterday). And it will evolve even more
as the compiler evolves. The interpreter is just a means for the
compiler to record good traces.

As I see it now, LuaJIT 2.x in interpreter-only mode on x86 does
not offer any tangible benefits over LuaJIT 1.x. On the contrary:
I guess it would give 2.x a bad reputation if the first release
would be faster than Lua but (usually) slower than LuaJIT 1.x.

> Ideally this would be packaged with compile time switches so
> that unsupported architectures could use the old VM.

The interpreter in LuaJIT 2.x is written in hand-tuned assembler.
There is no portable version in C. This would be a bit pointless,
as the standard Lua interpreter already solves that nicely.

But LuaJIT is a drop-in replacement for Lua. It has the same API
and ABI, i.e. you get binary link-compatibility. Adding both to a
multi-platform project and linking to Lua on platforms where
LuaJIT is not available is quite easy.

[Yes, you can turn off the trace compiler at runtime or disable
it at build time. The latter is mainly helpful for ports to new
architectures. You can do the port in two steps: first write the
interpreter, later add the arch-specific compiler backend.

It's also intended for those game consoles where generating
executable machine code at runtime is disabled for (silly)
security reasons. This way you'll benefit from the faster
interpreter at least.]

--Mike