Re: Mex API changes for 64bit

[David Bateman]

Christopher Hulbert wrote:
> On 6/3/07, David Bateman <address@hidden> wrote:
>> Christopher Hulbert wrote:
>> >
>> > Before matlab added mwSize, the API used integers. Some people (myself
>> > included) have not had the chance to go back and change my code. And
>> > if I did, I would need to test if the matlab header had mwSize
>> > defined, and handle the case when it does not. That's the reason I
>> > brought it up.
>> >
>>
>> Hi Chris,
>>
>> But if the underlying code uses long's then you'll have problems in any
>> case. The only functions I see that will really cause issues are the
>> mxSetIr, mxSetJc, mxGetIr and mxGetJc functions as these are really the
>> only ones that return arrays of type mwSize/mwIndex. For scalars long's
>> they will be converted to int's on the assignment and so if the matrices
>> you use are smaller than 2GB there should be no issue. So if you don't
>> use sparse matrices in your mex files, keeping the int's at least for a
>> while shouldn't be an issue.
> 
> What about the function:
> 
> mxArray *mxCreateNumericArray(mwSize ndim, const mwSize *dims,
>        mxClassID classid, mxComplexity ComplexFlag);
> 
> 
> The array of dimensions will be totally screwed up and I usually get a
> segmentation fault for this. If octave doesn't support this function,
> or others like it there's probably no problem.

Humm, yes they will also need changing. What a mess..

>> However, if you do use sparse matrices, and use a 64bit system then it
>> would be interesting to know what the effect would be. Did mathworks
>> implement conversion functions for mxSetIr, etc? If they didn't, as I
>> suspect, then unless you are in the native precision of the Octave
>> build, then your mex build will fail whatever flags you use.
> 
> Yes, Matlab keeps all the old functions defined as *_700. When
> defining MX_COMPAT_32, these are the functions that are linked into
> the mex function. So, yes, mxSetIr, etc. will still work in the old
> prototype provided that MX_COMPAT_32 is defined.

There should in fact be three versions:

1) native precision -> no coversion
2) 32bit precision on 64bit platform
3) 64bit precision on 32bit platform

Version 2) and 3) involve making a copy of the data. Realistically
though its only case 2) that will cause an issue as all the old code is
defined with "int" for the indexing, so I suppose mathworks only
supports case 1) and 2).

This is not that hard to add, for example mxGetIr would look something like

#if SIZEOF_INT != SIZEOF_OCTAVE_IDX_TYPE
mwIndex *
mxGetIr_730 (const mxArray *ptr)
{
  return ptr->get_ir ();
}

int *
mxGetIr_700 (const mxArray *ptr)
{
  mwIndex *Ir8 = ptr->get_ir ();
  mwSize nz = ptr->get_nzmax ();
  mwIndex maxidx32 = (1 << 31) - 1;
  int *Ir = 0;
  if (nz > maxidx32)
    error ("mxGetIr: index out of range");
  else
    {
      Ir = static_cast<int *> (mxMalloc (ptr->get_nzmax() * sizeof(int)));
      for (int i = 0; i < nz; i++)
        {
          if (Ir8[i] > maxidx32)
            {
              error ("mxGetIr: index out of range");
              mxFree(Ir);
              Ir = 0;
              break;
            }
          else
            Ir[i] = static_cast<int> (Ir8[i]);
        }
    }
  return Ir;
}

#if MX_COMPAT_32
#define mxGetIr mxGetIr_700
#else
#define mxGetIr mxGetIr_730
#endif

#else
mwIndex *
mxGetIr (const mxArray *ptr)
{
  return ptr->get_ir ();
}
#endif

and like that for every other function that is affected. This wouldn't
be hard to write, but is quite a bit of work. Also I have no means of
testing such a change, as I lack access to a 64bit platform with matlab
to test against. I'm therefore of the feeling to only support native
precision in mex files (which is already better than the current
situation as it allows 64 bit mex files), and let someone else write the
conversion code if they feel the need. At this point 64bit octave is
considered experimental in any case..

D.