Re: Luajit interpreter question
- From: Daniel Kolesa <quaker66@xxxxxxxxx>
- To: luajit@xxxxxxxxxxxxx
- Date: Wed, 3 Sep 2014 10:58:46 +0100
2014-09-03 10:44 GMT+01:00 Karel Tuma <kat@xxxxxx>:
> Excerpts from Mike Pall's message of 2014-09-03 02:45:45 +0200:
> > Daniel Kolesa wrote:
> > > 2014-09-02 21:20 GMT+01:00 Dibyendu Majumdar <mobile@xxxxxxxxxxxxxxx>:
> > > > I have a question regarding the Luajit interpreter. Is it possible to
> > > > write the Luajit bytecode interpreter in C - or does it rely upon
> features
> > > > only available in assembly language?
> >
> > Sure ... and the transitions to and from JIT-compiled code,
> > including register and stack snapshot handling. And error handling
> > plus frame unwinding. And bytecode recording. And metamethod
> > continuations. And the builtins written in assembler. Oh, and
> > performance won't be stellar either ...
>
> On a more technical note, it is possible to skew the current "most of hot
> paths
> in asm" to "bare minimum glue asm". Some low level machinery of
> MM/C/ASM/JIT mcode
> must be implemented in assembly as Mike mentions, however most of the
> actual
> opcodes can be written in C. Easiest way is to adapt vm_record for your
> "C stub" opcode implementations and use second level dispatch in C
> for your C opcode handlers (in similiar fashion how trace recorder does it,
> minus the restart). The C stub would return optional MM fallback for asm
> glue to continue on.
>
> Abusing fastfunc or lj_dispatch.c for this purpose is not advised as it is
> rather invasive and would be difficult merge-wise with LuaJIT.
>
> Also, meta dispatch is already mixed asm/c code (grep lj_meta_call),
> the asm part is mostly the bare minimum to call C fallback.
>
> All in all, it's not worth it IMO. You need to have fair understanding of
> the target ISA already for LuaJIT, so might as well port the whole
> interpreter and keep it fast at the same time.
>
> With fairly cosmetic changes to LuaJIT and Lua5.2+luaffi, it is possible
> to use both
> interchangeably, ie the desired result with the least effort.
>
>
LuaFFI is far from being actually useful. When I tried it was incredibly
buggy, only supported 2 or so architectures, didn't map to LuaJIT FFI
semantics closely and I managed to get it to fuck up on first non-trivial
example. So portability-wise and functionality-wise you're better off
actually using LuaJIT if you intend to use the FFI.
Other related posts:
