[Ecls-list] Support for libffi

[Juan Jose Garcia-Ripoll]

Hi,

given that libffi is shipped with OS X, I have decided to add support
for it. As of current git/CVS sources, if this library is present, ECL
will build the foreign function interface using this library. This
applies both to calling foreign functions and building of closures.

The code is still under probation. I have a couple of test cases in
the test suite which seem to work well enough. What makes me happy
also is the fact that it is much leaner and much more portable than
our current hacks in assembly language -- libffi works with intel/32,
intel/64 and powerpc, but perhaps many other platforms --.

However, this does not change the situation regarding the FFI and
CFFI. Namely, building dynamic calls to foreign functions is slow and
it has to be done for each function call. It is therefore still
preferred a solution based on C code, like the one UFFI/ECL currently
provides.

Regarding this I have been meditating. The problem is that, as I said,
CFFI bases the whole interface on a function that produces the code to
call a pointer to a function. I believe the right solution would be as
follows:

- Implement a generic function that uses the dynamic FFI to perform
the function call. This function should take a pointer, a list of
arguments and a description of the function arguments and output.
- Create a compiler macro for that function which does the following:
   * If the arguments to the function are not constant, then it
refuses to optimize and simply returns the original function call.
   * Otherwise the function call is replaced with a FFI:C-INLINE form.
   * If the module is a constant string, ensure that it is listed in
the linker flags that ECL will use, and replace the pointer with the
actual name of the function in the FFI:C-INLINE form.

This way even if we have the dynamic foreign function interface, the
function call can be optimized using the C compiler. The choice of one
or the other possibility would not be done by CFFI but by ECL,
depending on whether the code is interpreted or compiled.

Juanjo

-- 
Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain)
http://juanjose.garciaripoll.googlepages.com