[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: netCDF 2.3.2 on Alpha

> Organization: CMU
> Keywords: 199401170715.AA02073

Hi Lori,

> I had been using netcdf version 2.0 on a pmax_ul4 and was storing
> a structure that has the size 4 bytes.  (This structure has several
> dimensions).  I had a variable defined with NC_LONG (4 bytes).
> 
> Now, I've compiled version 2.3.2 for an alpha_osf1 and found out
> that the sizeof(long) is 8 bytes.  I noticed the comment
> in netcdf.h regarding a future change in the "typedef long nclong".
> so that nclong could be made to "int"(4 bytes) on the alpha.
> When is this change going to occur?

I can't say exactly, but we hope to get out a new release of netCDF by this
summer.

> In the current release, is there any way to store a multi-dimensional
> structure in 4 bytes?

Yes, the disk representation of the NCLONG type is still only 4 bytes, it
just gets represented in memory in 8 bytes on an Alpha.

> Is NC_LONG really stored as 8 bytes on the alpha?  or does the code
> somehow change is to 4 bytes as specified in the documentation?
> If it's stored as 8 bytes, is there a quick fix?

I've appended excerpts from my answer to an earlier query on this subject.
I hope it clarifies our intent.

__________________________________________________________________________
                      
Russ Rew                                              UCAR Unidata Program
address@hidden                                        P.O. Box 3000
(303)497-8645                                 Boulder, Colorado 80307-3000


Subject: Re: nclong  
Date: Tue, 04 Jan 1994 16:43:59 -0700
From: Russ Rew <address@hidden>

> So is it the intention that in the future data written to  
> variables / attributes of type NC_LONG should use the  
> C type 'nclong' rather than 'long'?  If so, do you have
> an idea about when you would be modifying the library to
> take this into account?   

Yes, that is our intention, and the changes should be in the next release.
I can't say how soon that version will be released, but I suspect it won't
be until mid-1994.  There may be a minor release before then fixing bugs.
There's still some work involved in changing all the documentation,
examples, and test programs to use nclong instead of long for declarations
of data variables.  We had given a rationale for this in a previous
announcement on the netcdfgroup mailing list:

    You should know, however, that the port of the FORTRAN interface to
    DEC's 64-bit Alpha machine uncovered an ambiguity in.  the netCDF
    specification.  In order to allow the writing of portable netCDF code,
    we have decided, after considerable discussion, to make a slight change
    to the netCDF specification.  This change will not affect the operation
    or portablility of existing or future netCDF code that is not intended
    to run on machines such as DEC's Alpha.  netCDF code for which such a
    machine is a possible platform, however, should be modified or written
    to adhere to the new specification.

    The change is the introduction of a new datatype, which is defined in
    the netCDF header file `netcdf.h'.  This new datatype is `nclong'.
    Maximally portable C code should use this datatype to hold all values of
    type NC_LONG.  For example:

            #include "netcdf.h"
            ...
            int    ncid, lid, status, dimids[NDIM];
            long   start[NDIM], count[NDIM];
            nclong data[SIZE];              /* NB: new datatype */
            ...
            lid    = ncvardef(ncid, "somelongvar", NC_LONG, dimids);
            ...
            status = ncvarput(ncid, lid, start, count, data);
            ...
            status = ncvarget(ncid, lid, start, count, data);

    Note that only variables for NC_LONG values should have type `nclong'.
    Other, traditionally `long' variables (such as the `count' and `start'
    vectors for hyperslab access) should remain as C `long's.

    FORTRAN programmers needn't worry about this change because portable
    FORTRAN code only has INTEGER values to play with (and not, for example,
    INTEGER*4, which is a non-portable datatype).  Thus, no change to the
    FORTRAN netCDF interface specification is required.

    This is the extent of the change.  The rest of this message gives the
    rationale for the change.

    The netCDF implementation and interface assume that a C `long' maps
    naturally into the 32 bit external integer representation of an NC_LONG.
    This is rooted in historical networking code traceable to the BSD
    functions ntohl() and htonl().

    With the introduction of DEC's Alpha machine, we are seeing reasons to
    question this.  The Alpha has 64 bit `long's and 32 bit `int's.  The
    natural and efficient choice for a C datatype which maps to an NC_LONG
    would, therefore, be `int' rather than `long'.  (We have encountered 64
    bit `long's before on the Cray, but there the `int' is also 64 bits, so
    there is no advantage to using different types).

    Furthermore, on the Alpha, the FORTRAN INTEGER type is 32 bits;
    therefore, keeping the C type as `long' for NC_LONG values would add
    costly transformations to the FORTRAN interface on this platform.

    On all platforms known to us (with the exception of the Alpha) the
    typedef for the new `nclong' datatype is

            typedef long nclong;

    and existing netCDF code will run without modification.  On the Alpha,
    however, the `nclong' typedef is

            typedef int nclong;

    We realize that changes to the interface specification are a hassle.
    The alternative in this case is to burden the Alpha platform (and any
    future system which makes similar design decisions) with greater memory
    usage and poor FORTRAN performance.

> Life is easier on my end if I can just modify the library
> to use nclong.  If it is something that the Unidata group
> has agreed should / will happen eventually it puts me on
> a much stronger footing.

Yes, you should be able to just use nclong, and realize that a recompilation
on alphas will be needed later when the typedef is changed.  By the way,
please don't use the other type names like "ncbyte" that were mistakenly
included in the netcdf 2.3.2 release, because the C interface and C++
interface currently disagree on what an "ncbyte" is; the C typedef has to be
removed from netcdf.h to even compile the C++ stuff.

...

--Russ