[Info-vax] Alpha Fortran data alignment

Bob Koehler koehler at eisner.nospam.encompasserve.org
Tue Aug 31 18:16:46 EDT 2010


In article <0c9b0338-b281-46e0-933d-b8933206a33d at i31g2000yqm.googlegroups.com>, tadamsmar <tadamsmar at yahoo.com> writes:
> I was checking the locations of variables.
> 
> If I run this:
> 
>         integer*2 prmidx
>         real*4 vlu
>         prmidx = 1
>         vlu = 10000000
>         call sub(prmidx,%loc(prmidx),%loc(vlu))
>         end
>         subroutine sub(prmidx,lp,lv)
>         integer*4 prmidx,lv,lp
>         type *,prmidx,lp,lv
>         end
> 
>           1      196608      196616
> 
> But if I change prmidx to real*4 in main and real*8 in
> the sub, I get:
> 
>   128.000036285423           196608      196612
> 
> 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.  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).

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

   The Fortran language standard itself says very little about the sizes
   of integers or the exact behaviour of different sizes.

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





More information about the Info-vax mailing list