Re: Luajit interpreter question
- From: Daniel Kolesa <quaker66@xxxxxxxxx>
- To: luajit@xxxxxxxxxxxxx
- Date: Wed, 3 Sep 2014 13:07:28 +0100
2014-09-03 13:03 GMT+01:00 Karel Tuma <kat@xxxxxx>:
> Excerpts from Daniel Kolesa's message of 2014-09-03 11:58:46 +0200:
> > 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.
>
> Indeed it needs some dusting off. The good part is that the Lua side of
> API is already implemented. As for cosmetic changes, those amount mostly to
> fixing Lua interop and ABI archdep:
>
> * Rip out all the archdep stuff, its mostly broken anyway. Dynasm
> does not support archs beyond what LuaJIT does already either.
> * Replace with libffi which is robust and well maintained.
> * Patch Lua to make it aware of ctype compare semantics.
> * Teach libffi new arch if it is missing your target (has plenty, but not
> all).
>
> It's not as hard as it sounds, though there is no code in the open
> (both libffi and luaffi) as there are interesting bussiness cases
> for this in the embedded/mobile space (aarch64, thumb2 .. yay for MIT).
>
> The idea here is to get good long term portability with not much effort,
> something I've been unable to achieve with LuaJIT (though eventually will
> need to port LJ to thumb2, as speed of current solution is rather abysmal).
>
>
>
Have you seen the Python cffi module? It uses libffi and is closely modeled
after the LuaJIT FFI.
Other related posts:
