<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>
