new branch in CVS archive

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

new branch in CVS archive

John W. Eaton-6
I created a new branch in the Octave CVS archive for your 64-bit
changes.  The branch tag is branch-64-bit-merge.

So far I've merged all the patches you sent for the
src/DLD-FUNCTIONS directory and added an --enable-64 option to the
configure script.  The default action is to check to see if pointers
are 64-bits, and if they are and a 64-bit integer type is available
(currently I check for int and long; should we also check for "long
long"?), then use the 64-bit integer type for the octave_idx_type,
which is defined in the new liboctave/oct-types.h file (more types may
be added later).  If the tests fail or if --disable-64 is given, we
revert to using int for array dimensions and indexing, same as we
currently use.

I hope to get all your other changes merged within the next week or
so.  After that, I will merge the changes on the branch with the main
trunk in the CVS archive, then make a new snapshot including the
changes.

jwe


Reply | Threaded
Open this post in threaded view
|

Re: new branch in CVS archive

David Bateman-3
John W. Eaton wrote:

>I created a new branch in the Octave CVS archive for your 64-bit
>changes.  The branch tag is branch-64-bit-merge.
>
>So far I've merged all the patches you sent for the
>src/DLD-FUNCTIONS directory and added an --enable-64 option to the
>configure script.  The default action is to check to see if pointers
>are 64-bits, and if they are and a 64-bit integer type is available
>(currently I check for int and long; should we also check for "long
>long"?), then use the 64-bit integer type for the octave_idx_type,
>which is defined in the new liboctave/oct-types.h file (more types may
>be added later).  If the tests fail or if --disable-64 is given, we
>revert to using int for array dimensions and indexing, same as we
>currently use.
>
>I hope to get all your other changes merged within the next week or
>so.  After that, I will merge the changes on the branch with the main
>trunk in the CVS archive, then make a new snapshot including the
>changes.
>  
>
Shouldn't the default behavior for now be to have this disabled by
default, at least till its tested a bit more? It seems without either
--enable-64 or --disable-64 the default is to enable it....

I'd also suggest including the "long long" class as a possible index,
since there is no reason to exclude this codes use on 32-bit platforms
even if it will be significantly slower....

Cheers
David




--
David Bateman                                [hidden email]
Motorola Labs - Paris                        +33 1 69 35 48 04 (Ph)
Parc Les Algorithmes, Commune de St Aubin    +33 1 69 35 77 01 (Fax)
91193 Gif-Sur-Yvette FRANCE

The information contained in this communication has been classified as:

[x] General Business Information
[ ] Motorola Internal Use Only
[ ] Motorola Confidential Proprietary


Reply | Threaded
Open this post in threaded view
|

Re: new branch in CVS archive

John W. Eaton-6
On  1-Apr-2005, David Bateman <[hidden email]> wrote:

| Shouldn't the default behavior for now be to have this disabled by
| default, at least till its tested a bit more? It seems without either
| --enable-64 or --disable-64 the default is to enable it....

I can switch the default when the branch is merged.  I ran the current
configure script on an Itanium system with --disable-64 and it prints

  64-bit array dims and indexing:     false

at the end of the run, so it seems to work for me.

| I'd also suggest including the "long long" class as a possible index,
| since there is no reason to exclude this codes use on 32-bit platforms
| even if it will be significantly slower....

Sure, I can include long long easily enough, but for 64-bit indexing
to really work, don't you also need 64-bit pointers?  Are there any
32-bit systems (what would that mean, 32-bit ints only?) that have
64-bit pointers, 32-bit ints, 32-bit long ints, and 64-bit long long
ints?

jwe


Reply | Threaded
Open this post in threaded view
|

Re: new branch in CVS archive

Clinton Chee-2
John,

Thanks for integrating the 64 bit changes, as well as the 32-64 switch
in the configure script.

Regarding the long long and similar issues, I guess we just need to be
careful and test it on each new 64bit systems. In a recent Intel Itanium
workshop I attended, I found this:

Unix/Linux (I32, LP64 model)
        => int-32   long-64   pointers-64

Windows 64 ( IL32, P64 model)
        => int-32   long-32   pointers-64

.... should we assume long long int in Windows64 is 64bit?


Another Note - for the fortran part (eg libcruft),  it should be
compiled with a -i8 switch, unless it default to 8 byte for fortran
integers.


Speaking of systems, I'm having rough time with our new Itanium64.
Things were fine when I completed the 64bit port on our old SGI IRIX
(MIPS compilers).

On the new Intel Itanium2, Intel IA64 compilers (icc.icpc, ifort)
compiles but hangs octave upon startup.
I tried GCC with g95 and it runs but fails with certain functions like
LU decomposition - may be g95 bug as you said).

PowerMAC G5 - have to rely on GCC and G95 - fail to link at the last
moment - complain about undefined functions.

My other options, are to verify the G95 bug if possible, find a new
Compiler???, or a another 64bit machine like an AMD64 cluster???









John W. Eaton wrote:

> On  1-Apr-2005, David Bateman <[hidden email]> wrote:
>
> | Shouldn't the default behavior for now be to have this disabled by
> | default, at least till its tested a bit more? It seems without either
> | --enable-64 or --disable-64 the default is to enable it....
>
> I can switch the default when the branch is merged.  I ran the current
> configure script on an Itanium system with --disable-64 and it prints
>
>   64-bit array dims and indexing:     false
>
> at the end of the run, so it seems to work for me.
>
> | I'd also suggest including the "long long" class as a possible index,
> | since there is no reason to exclude this codes use on 32-bit platforms
> | even if it will be significantly slower....
>
> Sure, I can include long long easily enough, but for 64-bit indexing
> to really work, don't you also need 64-bit pointers?  Are there any
> 32-bit systems (what would that mean, 32-bit ints only?) that have
> 64-bit pointers, 32-bit ints, 32-bit long ints, and 64-bit long long
> ints?
>
> jwe
>

--


----------------------------------------------------------------------------
Clinton Chee
Computational Scientist
High Performance Computing Unit
Room 2075, Red Centre
University of New South Wales
Australia 2035
chee at parallel stop hpc stop unsw stop edu stop au
Tel: 61 2 9385 6915
----------------------------------------------------------------------------