64 bit Octave

[John W. Eaton]

On 29-Aug-2003, Russell Standish <address@hidden> wrote:

| 1) I have succeeded in getting Octave-2.1.50 to compile with native
| SGI compilers (MIPS Pro). I've sent the patches through to John Eaton,
| so hopefully these will make it into the official sources.

I think I have applied one patch from you.  You can check to see if
everything you sent is in CVS.  If not, please send it again, as I
can't find any messages from you with patches that are still pending.

| 3) I am proposing to replace the relevant int variables with longs -
| longs are 64 bits wide on both these systems, and a long==int on a 32
| bit system. So my questions to this community are:
| 
|    i) Would such a change make a negative difference with other 64 bit
| systems - eg Solaris and IA64? I couldn't find any documentation on
| the IA64 compilers about the size of int and long

A change like this would be useful.  Please use size_t instead of
long.  Changing the types for the dimensions in the Array classes is
the place to start, I suppose.  Once you do that, you should get a lot
of warnings about type mismatches for all the other loop counters that
are ints.  Fixing that should not be too hard, but will probably be
time-consuming and a bit tedious.  The change will also affect most
user's .oct files, but I don't see a good way around that.

Since many files will need to be changed, it might help to do
something like the following so that we can make the change
incrementally:

  Introduce a new type name (using a typedef or #define) that is
  unique in config.h.  Somethine like IDX_T should do it.  For
  converting code, define it to be size_t (that will give you all the
  warnings).  Convert one file at a time, and submit the patches.  For
  my CVS copy, I will keep the definition as int, so we can continue
  to distribute a working Octave.  Once all the changes are made, then
  we can replace all IDX_T strings with size_t and increment the API
  version number.

Does that seem like a good plan?  I really don't want to get one very
large patch, as that will be difficult to review and apply (it could
result in a lot of conflicts).

Also, once we start, we could break up the work among several people.

|   ii) Are there any comprehensive test suites that could be used to
| exercise such a modified Octave to ensure the no bugs have been
| introduced?

Define comprehensive.  There is the set of tests distributed with
Octave (run with make check), but I am certain that running it will
not result in every bit of the code inside Octave being executed.

jwe