# foreign function interface

6 messages
Open this post in threaded view
|

## foreign function interface

 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]
Open this post in threaded view
|

## 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] > >
Open this post in threaded view
|

## RE: foreign function interface

Open this post in threaded view
|

## 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/peee-mail: [hidden email]