Re: Luajit interpreter question
- From: Karel Tuma <kat@xxxxxx>
- To: luajit <luajit@xxxxxxxxxxxxx>
- Date: Wed, 03 Sep 2014 11:44:33 +0200
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.
Other related posts:
