foreign function interface

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

foreign function interface

Paul Kienzle
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
[hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: foreign function interface

Andy Adler
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
> [hidden email]
>
>


Reply | Threaded
Open this post in threaded view
|

RE: foreign function interface

Lippert, Ross A.
In reply to this post by Paul Kienzle

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:[hidden email]]
Sent: Monday, December 16, 2002 11:40 AM
To: Paul Kienzle
Cc: [hidden email]
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
> [hidden email]
>
>



Reply | Threaded
Open this post in threaded view
|

Re: foreign function interface

Per Persson

On Monday, December 16, 2002, at 05:52 PM, Lippert, Ross A. wrote:

>
> 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()).
>

Maybe I'm misunderstanding what you mean, but I think that matwrap does
just that:
http://www-lnc.usc.edu/~holt/matwrap/

Regards,
Per

------------
Per Persson
Blekinge Institute of Technology
Dept. of Signal Processing and Telecommunications

www:   http://www.its.bth.se/staff/pee
e-mail: [hidden email]


Reply | Threaded
Open this post in threaded view
|

RE: foreign function interface

Lippert, Ross A.
In reply to this post by Paul Kienzle

Yeah, that looks like the right thing.  To make it even more
instantaneous, you have some standard .h files for common function
signatures and sed them into .h files for the function your after
and then call matwrap through system(), maybe.


-r

-----Original Message-----
From: Per Persson [mailto:[hidden email]]
Sent: Monday, December 16, 2002 12:00 PM
To: Lippert, Ross A.
Cc: Paul Kienzle; [hidden email]
Subject: Re: foreign function interface



On Monday, December 16, 2002, at 05:52 PM, Lippert, Ross A. wrote:

>
> 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()).
>

Maybe I'm misunderstanding what you mean, but I think that matwrap does
just that:
http://www-lnc.usc.edu/~holt/matwrap/

Regards,
Per

------------
Per Persson
Blekinge Institute of Technology
Dept. of Signal Processing and Telecommunications

www:   http://www.its.bth.se/staff/pee
e-mail: [hidden email]



Reply | Threaded
Open this post in threaded view
|

Re: foreign function interface

Paul Kienzle
In reply to this post by Lippert, Ross A.
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
[hidden email]

----- Original Message -----
From: "Lippert, Ross A." <[hidden email]>
To: "Andy Adler" <[hidden email]>; "Paul Kienzle"
<[hidden email]>
Cc: <[hidden email]>
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:[hidden email]]
> Sent: Monday, December 16, 2002 11:40 AM
> To: Paul Kienzle
> Cc: [hidden email]
> 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
> > [hidden email]
> >
> >
>
>