Re: Implementing loadlibrary, calllib, etc.

[John Swensen]

On Mar 24, 2010, at 4:06 PM, John W. Eaton wrote:

> On 24-Mar-2010, John Swensen wrote:
> 
> | I took a look at swig and it looks like extracting the necessary
> | bits from swig might be work work than it is worth.
> 
> I admit to not having looked at the swig internals.  I just assumed
> that it had some way of parsing header files to gather information
> about interfaces.  It is unfortunate but understandable if it is not
> modular enough to extract and reuse that part of the code.
> 
> | On the other
> | hand, maybe we should just use swig altogether and then wrap all the
> | specifics of loadlibrary, callib, etc. around swig.
> 
> Does ffcall work by invoking a compiler or by using some other tricks?
> If it avoids needing to call a compiler, then I think you want to use
> ffcall rather than swig, which I believe would force you to generate
> some glue code, compile it, then load the resulting shared library (as
> a .oct file) to access the library.  That sounds like it could be a
> lot slower than ffcall if ffcall simply loads the library and uses
> some magic to call functions directly.
> 

It does some magic based on platform and calling convention.  It is basically 
smart enough to know how a given compiler and calling convention puts things on 
the stack and does this appropriately.  Once I have a list of the parameter 
types, I can just iterate and add the passed in parameters to the variable list 
of arguments (doing type checking along the way to make sure the type passed in 
from octave matches the type from parsing the header file) and then make a call 
to a using a void* to the dlsym with this built-up list.

John Swensen