lua-users home
lua-l archive

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


I should correct myself: it seems that there is no bytecode frontend
in Lua JIT now, so it is not possible to create Lua JIT backend for
metalua.

The only option is to provide a source code backend for metalua. But
as far as I remember metalua can produce irreducable control flow
graphs (AST contains `Goto constructs). So translation into source is
not a straightforward task.

>
> "Given Metalua is written IN Lua (to my knowledge) - should it be used by
> LuaJIT-2, will it use the new byte-codes automatically or does it have them
> defined as constants that would need to be changed/altered?"
>

The answer is no: even if Lua JIT had bytecode frontend, metalua would
not be able to adapt itself automatically. Metalua inherited it's
backend from Yueliang which is just rewrite of several modules
(lcode.c, ldump.c) from C into pure Lua. When this modules change in
original Lua sources, metalua backend must be changed to accommodate
it.

--
e.v.e



On Tue, Nov 3, 2009 at 9:41 AM, Benjamin Tolputt
<btolputt@bigpond.net.au> wrote:
> Vyacheslav Egorov wrote:
>
> if it were compiled with LuaJIT-2, would it "just work"?
>
>
> No, it was already discussed before (when Mike announced that he
> altered bytecode format). Someone needs to provide a new bytecode
> backend.
>
>
> I am aware of the byte-code change. My question could be better defined as
>
> "Given Metalua is written IN Lua (to my knowledge) - should it be used by
> LuaJIT-2, will it use the new byte-codes automatically or does it have them
> defined as constants that would need to be changed/altered?"
>
> For most Lua libraries, I wouldn't even ask as I would assume (being written
> in Lua) that they'd just work. However, given the fact Metalua does play
> with the AST of code it compiles - I thought the question more pertinent.
>
> The next big library for me to work out how to get LuaJIT-2 compatible is
> Pluto. It didn't work with LuaJIT-1 for a variety of reasons, but I am
> hoping perhaps there is a way to get it working for this version of LuaJIT.
> Will wait on a more stable version though before I dig into that project.
>
> --
> Regards,
>
> Benjamin Tolputt
> Analyst Programmer