Xref: utzoo comp.lang.c:25048 comp.lang.fortran:2813 comp.lang.misc:3876
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!tut.cis.ohio-state.edu!att!ima!haddock!karl
From: karl@haddock.ima.isc.com (Karl Heuer)
Newsgroups: comp.lang.c,comp.lang.fortran,comp.lang.misc
Subject: Re: NOT Educating FORTRAN programmers to use C
Message-ID: <15643@haddock.ima.isc.com>
Date: 12 Jan 90 21:43:38 GMT
References: <649@chem.ucsd.EDU> <14191@lambda.UUCP>
Reply-To: karl@haddock.ima.isc.com (Karl Heuer)
Followup-To: comp.lang.misc
Distribution: na
Organization: Interactive Systems, Cambridge, MA 02138-5302
Lines: 41

In article <14191@lambda.UUCP> jlg@lambda.UUCP (Jim Giles) writes:
>From article <649@chem.ucsd.EDU>, by tps@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@haddock.isc.com or ima!haddock!karl), The Walking Lint
Followups to comp.lang.misc.