octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Further on MEX


From: David Bateman
Subject: Re: Further on MEX
Date: Wed, 07 Jan 2009 21:22:40 +0100
User-agent: Mozilla-Thunderbird 2.0.0.17 (X11/20081018)

John W. Eaton wrote:
On  7-Jan-2009, David Bateman wrote:

| Better to go for a fully matlab compatible MEX ABI | and fall under the same argument as distribution of MEX code as source | code.. That is of course if we can't just consider that the current | Octave MEX ABI isn't already separate enough from Octave and closer to | matlab that it doesn't already fall under the same argument.

What do you mean by ABI?  Do you mean that we should change Octave so
that a MEX file built with Matlab can run in Octave?

ABI = Application Binary Interface

FYI, here is a MEX file that can be compiled on a system that does not
have either Octave or Matlab and that can be run in either program:

  typedef void mxArray;

  extern void mexPrintf (const char *fmt, ...);
  extern mxArray *mxDuplicateArray (const mxArray *v);

  void
  mexFunction (int nlhs, mxArray *plhs[], int nrhs, const mxArray *prhs[])
  {
    int i;

    if (nlhs == nrhs)
      {
        mexPrintf ("copying inputs to outputs\n");
        for (i = 0; i < nrhs; i++)
          plhs[i] = mxDuplicateArray (prhs[i]);
      }
  }

Just compile with gcc -shared -fPIC -o foo.mex foo.c (you may need to
change the extension to mexglx so that Matlab can load it).

Since mxArray is an opaque type (all you ever need to use is a
pointer to it, and you never access contents directly) you don't need
to know its actual definition.  That's why the void typedef works and
you don't have to include mex.h for this struct definition.  You can
get the prototypes for the most of the interface from the
documentation.  The only sticking points are a few typedefs like
mxLogical, mxChar, mwSize, and mwIndex.  For those, you can probably
figure out what they are by trial and error.  Oh, and the only other
thing is you should avoid character data since Octave uses 8 bit
characters internally, but I think Matlab uses something wider.  So
direct character manipulation will probably crash either Matlab or
Octave (depending on what actual data type you choose for mxChar) or
I expect you will at least get some jumbled character strings.

I'd thought that matlab mex-function that are pre-compiled couldn't be used, and the above is a reasonable explanation of why. I had tried in the past with a couple of compiled mex-files without success. I'd be all for getting those typedefs right, even with workarounds for 8-bit character strings coded as UTF8, and that would all ow even pre-built mex-files to be used with Octave. We'd also then need to use the same mex extensions as matlab itself does though.

D.

--
David Bateman                                address@hidden
35 rue Gambetta                              +33 1 46 04 02 18 (Home)
92100 Boulogne-Billancourt FRANCE            +33 6 72 01 06 33 (Mob)



reply via email to

[Prev in Thread] Current Thread [Next in Thread]