Re: Rethinking octave_idx_type

[John W. Eaton]

On 11/28/2016 12:20 PM, Rik wrote:
> On 11/28/2016 05:28 AM, John W. Eaton wrote:

> > We should already be using F77_INT for the function declarations of any
> > Fortran code used by Octave so it should be fairly straightforward to
> > find all the locations that are affected.
>
> In liboctave, the shell command 'grep -rn '^\s*F77_INT ' * | wc -l' returns
> 16 so there aren't that many instances.

I see 15 .cc and .h files that use the name F77_INT currently:

  hg locate -I liboctave -I libinterp '*.h' '*.cc' | xargs grep -wl 
F77_INT | wc

These are all in function prototype declarations, not variable 
declarations in the actual uses of those functions.  And I see about 
1500 instances of F77_INT in those files.  So I think it will be a 
fairly big job.  However, it can be done incrementally because we can 
just keep F77_INT and octave_idx_type the same until we are done with 
the conversion.  We just need to change the typedef of octave_idx_type 
to be int64_t while leaving F77_INT as int32_t to find the places that 
need to be changed.  But the configure script doesn't need to change 
yet, so builds should continue to work properly even when the changes 
are incomplete.

> In terms of performance, we currently have a static interface where
> octave_idx_type and F77_INT are matched up during configure.  Now there
> will be a runtime check every time a Fortran routine is called.  This will
> be slower, but manageable as long as the work done in the Fortran routine
> is large relative to the call overhead.

It should be pretty minimal as the check could be inlined:

  inline F77_INT
  to_f77_int (octave_idx_type x)
  {
    if (x > std::limits<F77_INT>::max () || x < 
std::limits<F77_INT>::min ())
      out_of_range_error (x);

    return static_cast<F77_INT> (x);
  }

So in the successful case, it's just a few instructions.

> Is there anything that will need to change for people who are using the
> mkoctfile interface to create their own links to Fortran code?  Will they
> need to re-write their code to invoke to_f77_int?

Yes, that code will have to change to work properly on 64-bit systems. 
But we can experiment with this prior to the release and hopefully fix 
everything in Octave Forge at least.  Since these changes shouldn't 
cause trouble if octave_idx_type == F77_INT, they should be backward 
compatible with 4.2.0.  To continue to support earlier versions, you 
would just need to provide a typedef for F77_INT that is equivalent to 
the type of octave_idx_type.

jwe