[Ecls-list] CFFI and DFFI

[Luis Oliveira]

Juan Jose Garcia-Ripoll
<juanjose.garciaripoll at googlemail.com> writes:

> UFFI, for instance, has a simpler set of function types and arguments
> it supports (pointers, ints, floats, etc) because they are less likely
> to change with the ABI.

Can you be more specific? What CFFI types are problematic?


> Work on ECL's DFFI only began because of CFFI. DFFI is a mixture of
> assembly and C code to generate dynamically function calls to foreign
> functions. I must say I myself do not like it. I was only able to code
> the x86/32 bit version, M. Goffioul hacked the x64_64 bits port
> without even knowing x86_64 assembler. But that is all. Should we want
> to use it on other platforms I would need to contact a skilled (or
> reckless) coder that does it for us. But even then I would not trust
> it as much as the code generated by a C compiler, which does know the
> ABI very well, including the choices of registers it does when passing
> structures and other things.

Perhaps using libffi (for DFFI) would be a good, solid approach?
<http://sourceware.org/libffi/>


> The fact that ECL is forced to use DFFI because all other lisps do is
> kind of awkward. ECL uses a C compiler, my gosh, that should put us on
> an advantage position, having all the type information, being able to
> code a FFI call with just one line of C, no need for building callback
> code on the fly, or other hacks... However, as it is, with CFFI this
> has not been possible.

Having a dynamic FFI seems useful for interpreted code, for libraries
that for some reason or another really do have to be accessed via
dlopen/dlsym, and during development -- e.g., using the REPL.

BTW, regarding the OP's problem, some UFFI libraries such as CLSQL pass
non-constant arguments to UFFI:LOAD-FOREIGN-LIBRARY as well. I assume
that would be a problem for ECL as well.


> I just cited an example back from my recollections when initially
> working on the CFFI port. CFFI dropped all type information, varargs
> was completely ignored, this and other problems made it impossible for
> us to produce a single C function call that was type accurate and
> could be used by the compiler.

At what point does CFFI "drop all type information"? That doesn't sound
right. Again, I'm not aware of any way to define varargs functions in
UFFI/DFFI. If there were, CFFI could use it.


> To this you should add that CFFI only contemplates dynamically loaded
> libraries, no possibility of letting a proper linker resolve symbols:
> one has to use always dlopen, etc, as you said, because other lisps
> do. In ECL's UFFI we can just compile in the library.

I'm pretty sure I've done that with CFFI and ECL on darwin/ppc, so I
don't think that claim is correct.


>> We're certainly open to patches/suggestions that help us better support
>> ECL's static and dynamic FFIs.
>
> Right now I do not have time to work on that. To begin with, it should
> be possible to use CFFI as just a kind of lisp-SWIG, in which files
> with foreign function calls are compiled before being loaded.

That's how CFFI-using libraries are usually loaded, so no problem
there. (I should mention again that having a dynamic FFI seems useful
nevertheless.)


> That, and keeping more accurate information

What information?


> allowing libraries to be statically specified

The only problem I see here is how to specify alternatives.
E.g.: (cffi:load-foreign-library '(:or "libfoo.so.1" "libfoo.so"))
How can we do this why ECL's static FFI?


-- 
Luís Oliveira
http://student.dei.uc.pt/~lmoliv/