Re: foreign function interface

[Paul Kienzle]

There are two big advantages to a direct FFI: it does not require a compiler
(which can be an issue on Windows systems) and it is completely independent
of which octave version is running (so long as that version supports FFI of
course).  Right now you have to recompile everything on your path if you
change Octave versions.

Paul Kienzle
address@hidden

----- Original Message -----
From: "Lippert, Ross A." <address@hidden>
To: "Andy Adler" <address@hidden>; "Paul Kienzle"
<address@hidden>
Cc: <address@hidden>
Sent: Monday, December 16, 2002 11:52 AM
Subject: RE: foreign function interface


>
> What about, instead, something less ambitious, but almost as powerful.
Suppose
> that one had an "instant oct-file" version of mkoctfile, which produces a
.oct
> wrapper for a given function from a given library given some signature
information
> (and perhaps C, C++, Fortran linkage information).  This instant-octfile
program
> would be run outside octave (or within octave via system()).
>
> e.g.
> % inst-oct sqrt /lib/libmath.a -o ~/octave/oct-files/mysqrt.oct -sig
'(double)*f(double)'
>
> I think in practice, people would be just happen to ^Z out of octave, do
something
> quick to their favorite lib, and then jump back in and have the DLD
available.  Perhaps
> some octave functions could be written which supply common signatures to a
> system('inst-oct ...') call.
>
> Anothing way to get .oct files written quickly, which people may like a
lot if some sort
> of template (like the famous oregonator example) file which can be
instantly conjured into
> an editor (which saves us the time to look up the oregonator example in
the handbook).
> A well commented template can be the key to fast function development.
>
> -r
>
> -----Original Message-----
> From: Andy Adler [mailto:address@hidden
> Sent: Monday, December 16, 2002 11:40 AM
> To: Paul Kienzle
> Cc: address@hidden
> Subject: Re: foreign function interface
>
>
> This is a great idea.
>
> The best similar concept I'm aware of is Perl's Win32::API.
> It is used like this:
>     use Win32::API;
>     $GetPID = new Win32::API("kernel32", "GetCurrentProcessId", '', 'N');
>     $PID = $GetPID->Call();
>
> This allows direct access to windows dll's.
> The only tricky part is packing data into the appropriate
> structs for each dll to use.
>
> In order to offer a similar function from octave, we would
> need something like perl's "pack" function.
>
> I was thinking (for other reasons) that a we need a "sread"
> and "swrite" analgous to "fread" and "fwrite".
>
> These functions would read and write to a string (or other
> byte data vector) rather than to a file.
>
>
> Andy
>
>
> On Sat, 14 Dec 2002, Paul Kienzle wrote:
>
> > Hi, all.
> >
> > I've been trying to think of ways to lower the barrier for contributions
to
> > octave. In particular, there are a lot of prefectly good libraries out
there
> > that people could call if it were easy to call them. While oct-file
> > programming is much easier than mex-file programming, I believe we can
do
> > even better than that.  I would like for us to be able to directly call
> > sharable object code from a script without writing a DEFUN_DLD wrapper.
> >
> > The technique is called variously a foreign function interface or a
native
> > call interface.  Given a native type signature (e.g., double
sin(double)) we
> > should be able to have a definition ffi("libm","sin","dd","Nsin") which
> > defines the octave function Nsin, which you could then call from octave
as x
> > = Nsin(y).  For extra convenience it would be nice to automatically
apply
> > scalar functions like this element-wise on a vector.  Functions like
sqrt
> > would be a problem, but these could be handled easily enough from a
script
> > such as: function x=sqrt(y), x = Nsqrt(abs(y)); x(y<0) *= 1i; end
> >
> > There are three approaches that I've encountered for doing this:
> >
> > (1) fortran style:  everything must be a pointer.  This is less than
ideal
> > since a lot of functions don't operate on pointers, so users would have
to
> > wrap the library functions with functions that accept pointers.  This is
> > still easier than figuring out how to use the octave_value properly.  R
> > seems to do this.
> >
> > (2) predefined type signatures: predefine functions for all the possible
> > type signatures that you might want to call.  In principle you could
write
> > special functions for each possible type signature.  E.g.,
ffi(...,"dd",...)
> > would call a function like dd_chain(double (*f)(double),octave_value
&ov)
> > which internally would be defined like:
> > octave_value dd_chain(double (*f)(double), octave_value &ov)
> >     Matrix in(ov.matrix_value());
> >     Matrix out(ov.rows(),ov.columns());
> >     const double *pin = in.data();
> >     double *pout = out.fortran_vec();
> >     for (int i=0; i < in.length(); i++) { pout[i] = (*f)(pin[i]); }
> >     return octave_value(out);
> > The problem with this approach is that the various combinations of
> > void/character/integer/float/double/complex, and pointers thereto leads
to a
> > small
> > explosion in the number of functions.  I believe Perl does this with its
> > native call interface (or it will in Perl6 whenever that is released.)
> >
> > (3) compiler-like call.  Build a stackframe, jump to the function and
await
> > the return.  This is the ideal way since it is not limited in terms of
the
> > number or type of paramters, but it is very machine dependent.  libffi
> > provides this for a number of platforms.
> >
> > Does anyone have experience in this sort of thing? Does it sound like a
> > worthwhile venture?
> >
> > Paul Kienzle
> > address@hidden
> >
> >
>
>