<html><head><meta http-equiv="Content-Type" content="text/html; charset=ANSI_X3.4-1968"><title>3.2. Two kinds of FFI</title><link rel="stylesheet" href="ecl.css" type="text/css"><meta name="generator" content="DocBook XSL Stylesheets V1.75.2"><link rel="home" href="index.html" title="The ECL manual"><link rel="up" href="ch18.html" title="Chapter 3. Foreign Function Interface"><link rel="prev" href="ch18.html" title="Chapter 3. Foreign Function Interface"><link rel="next" href="ch18s03.html" title="3.3. Foreign objects"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">3.2. Two kinds of FFI</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="ch18.html">Prev</a> </td><th width="60%" align="center">Chapter 3. Foreign Function Interface</th><td width="20%" align="right"> <a accesskey="n" href="ch18s03.html">Next</a></td></tr></table><hr></div><div class="section" title="3.2. Two kinds of FFI"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="ext.ffi.dffi"></a>3.2. Two kinds of FFI</h2></div></div></div><p><span class="application">ECL</span> allows for two different appraoches when building a <span class="application">FFI</span>. Both approaches have a different implementation philosophy and affect the places where you can use the <span class="application">FFI</span> and how. </p><div class="variablelist"><table border="0"><col align="left" valign="top"><tbody><tr><td><p><span class="term">Static <span class="application">FFI</span></span></p></td><td><p>For every foreign function and variable you might need to use, a wrapper is automatically written in C with the help of <a class="xref" href="re14.html" title="ffi:c-inline"><code class="function">ffi:c-inline</code></a>. These wrappers are compiled using an ordinary C compiler and linked against both the foreign libraries you want to use and against the <span class="application">ECL</span> library. The result is a <acronym class="acronym">FASL</acronym> file that can be loaded from <span class="application">ECL</span> and where the wrappers appear as ordinary lisp functions and variables that the user may directly invoked.</p></td></tr><tr><td><p><span class="term">Dynamic <span class="application">FFI</span></span></p></td><td><p>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.</p></td></tr></tbody></table></div><p> </p><p> </p><div class="figure-float" style="float: left;"><div class="figure"><a name="fig.ffi"></a><p class="title"><b>Figure 3.1. FFI components</b></p><div class="figure-contents"><div class="mediaobject" align="center"><table border="0" summary="manufactured viewport for HTML img" cellspacing="0" cellpadding="0" width="300"><tr><td align="center"><img src="figures/ffi.png" align="middle" width="300" alt="FFI components"></td></tr></table></div></div></div><br class="figure-break"></div><p>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 <span class="application">ECL</span> 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.</p><p>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 <span class="application">ECL</span>, to know very well both the assembly code of the machine <span class="application">ECL</span> runs on and the calling conventions of that particular operating system.</p><p><span class="application">ECL</span> currently supports the static method on all platforms, and the dynamical one a few of the most popular ones, shown in <a class="xref" href="ch18s02.html#table.dffi" title="Table 3.1. DFFI support">Table 3.1</a>. You can test if your copy of <span class="application">ECL</span> was built with DFFI by inspecting whether the symbol <span class="symbol">:DFFI</span> is present in the list from variable <span class="symbol">*FEATURES*</span>.</p><div class="table"><a name="table.dffi"></a><p class="title"><b>Table 3.1. DFFI support</b></p><div class="table-contents"><table summary="DFFI support" border="1"><colgroup><col><col><col></colgroup><thead><tr><th>Architecture</th><th>Support</th><th>Operating systems</th></tr></thead><tbody><tr><td>Intel x86 32 bits</td><td>Complete</td><td>Any with SysV ABI (Linux, BSD), Windows, OS X</td></tr><tr><td>Intel x86 64 bits</td><td>In progress</td><td>SysV ABI</td></tr><tr><td>PowerPC 32 bits</td><td>In progress</td><td>OS X</td></tr></tbody></table></div></div><br class="table-break"></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="ch18.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="ch18.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="ch18s03.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Chapter 3. Foreign Function Interface </td><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td><td width="40%" align="right" valign="top"> 3.3. Foreign objects</td></tr></table></div></body></html>