[Info-vax] Alpha Fortran data alignment

[glen herrmannsfeldt]

Bob Koehler <koehler at eisner.nospam.encompasserve.org> wrote:
(snip)

>>         call sub(prmidx,%loc(prmidx),%loc(vlu))
(snip)
 
>> It appear that 8 bytes are allocated for an integer*2 and 4 bytes are
>> allocated for a real*4
 
>   There are some Fortran compilers which will allocate local variables
>   in the order declared, I've used them in the past.  But Fortran does
>   not require that.  Unless you put the variables in a data structure
>   or a common block _and_ tell the compiler to pack the data, Fortran 
>   is free to allocate the variables any way it wants.
 
>   Which means you've discovered where a particular version of the Fortran
>   compiler on Alpha will put the variables, but not how much space is
>   allocated since the compiler could be storing something else, or
>   just padding, between them.
 
>   However, if I ask the compiler what it actually allocated 
>   ($fortran/list/machine_code), I see that yes, indeed, the current
>   version here on Eisner allocates 8 bytes for an integer*2 and
>   4 bytes for a real*4.
 
>   Alphas are 64 bit systems.  It's slow to access anything smaller than
>   32 bits.  

As I remember it, the early Alpha only did 32 bit and 64 bit load/store,
anything smaller was done in registers.  The story I heard was that
smaller load/store were added for the benefit of Windows NT support,
but I don't know that I followed it that far.

>   So allocating and accessing 16 bits for integer*2 would be
>   slower.  The Fortran compiler promises requires certain behaviour when 
>   a 16 bit integer is used, but does not promise implementation.  As long 
>   as the program produces the same results that a real 16 bit integer 
>   would produce, the compiler can do what it wants.  It looks like the 
>   compiler write choose to allocate an Alpha's native 64 bit location 
>   since he didn't want to allocate slow 16 bits and could still produce 
>   the correct behaviour (to within the limits dictated by the incorrect 
>   code).

Even more, if you consider the effects of cache lines and such
it may make more sense to fill up the 64 bits.  
 
>   Why not?  I've worked with 36 bit word systems and they promise even
>   less precise behaviour when you tell them to use 16 bit integers in
>   Fortran (I don't recall, it either used 18 or 36 bits, but it did
>   so whether the operation produced the same result as 16 bits or not).

Well, INTEGER*2 was IBM's way of asking for two bytes, but the
standard never said so.  The Fortran-10 compiler for the PDP-10 
accepts REAL*4 and REAL*8 for 36 and 72 bit floating point,
respectively, but that doesn't have anything to do with bytes.
I don't believe that it does INTEGER*2.
 
>   The Fortran language standard itself says very little about the sizes
>   of integers or the exact behaviour of different sizes.

There might be minimums, but I don't believe a maximum.
With the new KIND system, one specifies the number of decimal
digits needed, and the system supplied a big enough KIND, if
one is available.
 
>   If you need to access an external data stream containing 16 bit
>   integers you need to, and can, tell this Fortran compiler to pack the
>   data _and_ put it into a structure or common, and then it will
>   allocate 2 bytes.  Other compilers might not be so accomodating.  The
>   Fortran standard doesn't require them to be (at least not as of
>   the Fortran 95 standard, which was the last one I can find compilers
>   for).

Well, at least an array should have consecutive elements.
Even so, there is no requirement that they have a certain size.

-- glen