At 11:57 PM 2/7/01 -0500, Aleksandar Donev wrote:
>Me complaining again,
>
> > It isn't standard because it would break portability. The standard
> > tends to disallow things that will result in different behavior on
> > different platforms. That doesn't mean it might not be supported
> > on the individual platforms, but the results might be different.
>
>If this is true than TRANSFER breaks portability as well, as do all routines
>that have the clause "in a processor dependent manner" in them (and these
>are abundant). I mean, equivalence is internally a relatively identical
>concept on most machines--the two data items being equivalenced are treated
>as two different objects (two entries in the symbol table), but they have
>the same address (which at least for scalars are almost always just a
>default integer). So although portability is important, making simple tasks
>difficult is not in my view the goal of portability. No wonder nobody (or
>few do, sorry) does low-level programming in Fortran and vendors have no
>motivation to implement things like TRANSFER efficiently!
Language standards describe both what is legal to write in a language and
what those legal constructs mean. Standards writers get very nervous when
that meaning is processor dependent. That doesn't mean they never describe
things a processor dependent, but they do try to minimize the extent to
which they do it.
Note that using EQUIVALENCE in the way discussed in this thread is _not_
standard-conforming. When you assign to the REAL variable in the
EQUIVALENCE, the INTEGER variable becomes undefined and you are prohibited
from referencing it until you define the INTEGER variable (rendering the
REAL variable undefined). I know of no compiler that enforces this
prohibition, but that's a different issue. As far as the standard is
concerned, the only purpose for an EQUIVALENCE between types with different
representations is to save memory.
TRANSFER is a special case, because one of the reasons for adding it was to
make it easier to identify the potentially non-portable portions of a
code. EQUIVALENCE could be used both legally to do things that are
entirely portable and illegally to do things that are processor-dependent
and likely not portable. Thus, scanning for EQUIVALENCE wasn't necessarily
helpful in identifying parts of a code that might be problematic in porting
a that code to a new platform. Since the functionality of TRANSFER
corresponds to the illegal use of EQUIVALENCE, its presence in a code is a
more reliable indicator of problematic code.
> > *YOU* may happen to know that you have arranged things so that
> > integer(kind=i_64) takes the same space as your real(kind=r_64), but
> > that is not a portable assumption. The same code on another machine
> > might not have this property (depending on exactly how you defined
> > your kinds). You may have been pretty careful about arranging that
> > this will be true, but the compiler and the standard doesn't know that
> > you have been careful about that (and I absolutely guarantee you that
> > a lot of other people haven't).
>
>It is not the compiler's job to make sure the programmer knows what he is
>doing. If one embarks on using low-level routines like bit manipulation, he
>needs to know what he is doing and how many bits his integer or real is, or
>what the actual implementation of these types is, etc. Why else would anyone
>use bit manipulation?
Unlike TRANSFER, EQUIVALENCE wasn't intended for bit twiddling. It can
(illegally) be used that way, but the rules for EQUIVALENCE reflect only
its portable uses.
>To come back to the point, EQUIVALENCE is inferior to TRANSFER in terms of
>its "elegance", and I would love to forget about its caveats and use
>TRANSFER if vendors make sure the *simple* cases of its use are recognized
>and implemented well. For the complex array-based uses of TRANSFER I can
>only hope...
Given the current state of compiler implementations of TRANSFER, I would
attempt to minimize the size of the primary argument to TRANSFER, so that
if the copy takes place, its cost is minimized.
It's less clear what to do if your choice is many small TRANSFERs or one
big one. My gut reaction is still to go with the many small TRANSFERs, on
the theory that if the one big TRANSFER does a copy, it will almost
certainly not overlap other computation, but that there is at least a
possibility that copies associated with small TRANSFERs will overlap with
other computation taking place at the same time.
--
Kurt W Hirchert [log in to unmask]
UIUC Department of Atmospheric Sciences +1-217-265-0327
|