ECL allows for two different appraoches when building a FFI. Both approaches have a different implementation philosophy and affect the places where you can use the FFI and how.
For every foreign function and variable you might need to
use, a wrapper is automatically written in C with the help of
First of all, the foreign libraries are loaded in memory using the facilities of the operating system. Similar routines are used to find out and register the memory location of all the functions and variables we want to use. Finally, when actually accessing these functions, a little piece of assembly code does the job of translating the lisp data into foreign objects, storing the arguments in the stack and in CPU registers, calling the function and converting back the output of the function to lisp.
As you see, the first approach uses rather portable technices based on a programming language (C, C++) which is strongly supported by the operating system. The conversion of data is performed calling routines in the ECL library and we need not care about the precise details (organizing the stack, CPU registers, etc) when calling a function: the compiler does this for us.
On the other hand, the dynamic approach allows us to choose the libraries we load at any time, look for the functions and invoke them even from the toplevel, but it relies on unportable techniques and requires from us, the developers of ECL, to know very well both the assembly code of the machine ECL runs on and the calling conventions of that particular operating system.
ECL currently supports the static method on all platforms, and the dynamical one a few of the most popular ones, shown in Table 3.1. You can test if your copy of ECL was built with DFFI by inspecting whether the symbol :DFFI is present in the list from variable *FEATURES*.
Table 3.1. DFFI support
|Intel x86 32 bits||Complete||Any with SysV ABI (Linux, BSD), Windows, OS X|
|Intel x86 64 bits||In progress||SysV ABI|
|PowerPC 32 bits||In progress||OS X|