Re: 64 bit Octave

[Russell Standish]

John W. Eaton wrote:
> 
> 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.

Ah - I have to figure out this CVS thingy...

> 
> | 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.  

I thought about this. Is it guaranteed that size_t will always be an
integral type? If so, then this will be the natural type to use.

> 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.
> 

This seems sensible.

> 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.
> 

One may not get much help from the usual compiler, such as gcc, since
size_t usually equivalent to int on 32 bit systems anyway. Maybe we
could define IDX_T to be long long to get the compiler to point out
coding errors...

> |   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
> 

It's definitely worth doing though. Will need to check DejaGNU...

----------------------------------------------------------------------------
A/Prof Russell Standish                  Director
High Performance Computing Support Unit, Phone 9385 6967, 8308 3119 (mobile)
UNSW SYDNEY 2052                         Fax   9385 6965, 0425 253119 (")
Australia                                address@hidden             
Room 2075, Red Centre                    http://parallel.hpc.unsw.edu.au/rks
            International prefix  +612, Interstate prefix 02
----------------------------------------------------------------------------