NOT Educating FORTRAN programmers to use C

[Karl Heuer]

In article <14191 at lambda.UUCP> jlg at lambda.UUCP (Jim Giles) writes:
>From article <649 at chem.ucsd.EDU>, by tps at chem.ucsd.edu (Tom Stockfisch):
>>[Because the F77 standard allows a double precision array to be equivalenced
>>to an arbitrary point in a real array, double precision objects might not be
>>aligned and hence Fortran cannot make use of the double-word fetch.]
>
>...The only way for optimization to be inhibited would be if he equivalenced
>two different double word objects to an array of singles - AND the two
>equivalances were an odd number of words apart!  In this case, most
>implementations I've seen will still do the fast loads/stores/ on the
>properly aligned data and will issue a warning about the other.

And if the misaligned double is passed (by reference) as an argument to a
separately-compiled function, does it still work?  If so, it seems that the
compiler is forced to assume possible misalignment of doubles received as
formal parameters.  This is not terribly efficient.

>>A reasonable C implementation on this machine would simply require
>>type "double" to be aligned on 8 byte boundary.
>
>Which just means that C CAN'T do something that Fortran CAN.

Much like the way that Fortran CAN'T support a function that can be passed the
same object in two distinct arguments, because it wants to be able to assume
the lack of aliasing.

>And, if C DID allow doubles on odd words, it would face the same optimization
>problems - worse: because the compiler can't necessarily tell if a
>pointer-to-double will be properly aligned until run-time.

You're hypothesizing a feature and then assuming that it would be badly
implemented.  If I were implementing a language extension to allow misaligned
objects (not necessarily restricted to |double|), I would do so with a new
type qualifier |unaligned|.  Given |int unaligned x|, |&x| would have the
type |int unaligned *|, which could not be safely stored in a plain |int *|.
Fetching would be done the "hard way" only if the object has the |unaligned|
qualifier.  If my earlier conjecture about Fortran's assumptions is correct,
this C extension would be more efficient than Fortran.

Karl W. Z. Heuer (karl at haddock.isc.com or ima!haddock!karl), The Walking Lint
Followups to comp.lang.misc.