[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Mike Pall's standalone FFI: a dream?
- From: Axel Kittenberger <axkibe@...>
- Date: Sat, 4 Jun 2011 21:50:52 +0200
I see this LuaJIT.ffi to vanilla Lua suggestion coming up repeatedly.
Last time I remember it was more or less talked the same.
My suggestion was when going that route to make a tool with its own
syntax that can generate FFI-code just as well as
However the conlusion back then was, if you need to press out the
latest bit of speed, go FFI and forget about vanilla. If you don't
want to do that, forget about the FFI and write classical C bindings,
you don't throw that much performance out of the window, since LuaJIT
still works nicely with vanilla bindings as well.
On Fri, Jun 3, 2011 at 12:33 PM, Justin Cormack
> On Thu, Jun 2, 2011 at 7:17 PM, Florian Weimer <email@example.com> wrote:
>> * Lorenzo Donati:
>> > I'm wondering if there are any chances that LuaJIT FFI will ever
>> > become also a standalone module for stock Lua.
>> What about the other way round: add a C interpreter to LuaJIT and make
>> the FFI use libffi? There's still a missing feature, though: C
>> structure layout is quite architecture-specific (especially for
>> bitfields), so you'd still need some code to cover that.
> I also wondered about adding enough introspection to LuaJIT such that you
> could write a program to generate C bindings from a LuaJIT ffi binding. Not
> sure how much work would be involved.