Re: Question about LuaJIT's future FFI/Struct Extension

[Peter Cawley <lua@...>]

On Wed, Mar 17, 2010 at 5:42 PM, Duncan Cross <duncan.cross@gmail.com> wrote:
> (This is directed at Mike Pall, but I thought the subject might be of
> interest to other people as well.)
>
> I'll get to the point: How far away do you think you are from
> finalizing the API for the FFI/struct extension for LuaJIT? What is
> its priority relative to the other things you've got going on, now
> that the x64 port is complete?

Along the same lines, I noticed that in a recent project, most of my
C(++) glue functions did very simple things - read some values off the
Lua stack, call some C++ method, and push the results back onto the
stack. It seems to me rather wasteful for LuaJIT to setup a stack,
call my C(++) function, have that call back to the API to read/write
values, then have LuaJIT tear the stack down again. For a large
proportion of these functions, I consider it plausible that LuaJIT
could disassemble the C(++) function, replace the calls to the Lua API
with inline assembler, and then be able to call the resulting function
without having to mess around with moving stuff on and off the stack -
effectively turning arbitrary C(++) functions into fast functions.
Obviously the whole disassembling and re-writing process is more
complex than the proposed FFI interface in [1], but it would allow the
re-use of existing binding code, and also sidestep issues relating to
the differing ways in which compilers implement things like (multiple,
virtual) inheritance and (pure) virtual functions. Once the LuaJIT
codebase reaches some stable state, I'd be interested into looking
into implementing the above concept myself.