[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