[Ecls-list] FFI paradigms (was Re: ECL 10.2.1 RC)

Juan Jose Garcia-Ripoll juanjose.garciaripoll at googlemail.com
Sat Feb 13 23:00:07 UTC 2010


On Sat, Feb 13, 2010 at 11:53 PM, Matthew Mondor
<mm_lists at pulsar-zone.net>wrote:

> On Sat, 13 Feb 2010 23:36:13 +0100
> Juan Jose Garcia-Ripoll <juanjose.garciaripoll at googlemail.com> wrote:
>
> > Nothing to add here. UFFI was and is very limited. CFFI is probably the
> way
> > to go for portable code, and is even favored for standardization.
> However,
> > 1) the ECL backend is crappy, 2) it will also not support GCC alignment
> > extensions and 3) it may still have problems with structures if a
> compiler
> > makes weird design choices. Problem 3) is solved by the fact that there
> are
> > more eyes watching CFFI and ensuring that it works.
>
> And I guess that 4) it has various external dependencies (at least the
> current implementation), 5) performance might be affected because of
> the dynamic function lookup per call :)  But indeed for portability
> it's the best target currently...


None of these are absolutely unsolvable. Your design choices for structures
could be ported to the CFFI backend so that it no longer relies on function
calls to access foreign data, but rather creates C-INLINE forms. The same
thing could be said about foreign functions. But this needs somebody to sit
and carefully study how to modify CFFI to add these improvements -- and
whether it is actually possible or changes in the API/semantics are
required.

Juanjo

-- 
Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain)
http://juanjose.garciaripoll.googlepages.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/ecl-devel/attachments/20100214/b00da74d/attachment.html>


More information about the ecl-devel mailing list