Re: Fortran's Equivalence

[kst@sd.aonix.com (Keith Thompson)]

In <dewar.859897867@merv> dewar@merv.cs.nyu.edu (Robert Dewar) writes:
> Keith argues that somehow unchecked conversion is more guaranteed by the
> RM than address overlay. I find all these arguments bogus. First they
> are rather useless pedantry, if you are in the business of trying to
> find out what the RM absolutely guarantees will work in chapter 13,
> even with annex B implemented, you will likely be disappointed. Second
> in this particular case, there simply are no guarantees on either side.
 
Ok, pedantry aside, I would still make the following suggestions:
 
1. If you're going to implement overlays using address clauses, it's safer
   (and can't do any harm) to declare all the overlaid objects as aliased.
   Pragma Volatile might be even better.  Perhaps someone more familiar
   with this than I am can elaborate (or execute, or evaluate 8-)}).
 
2. If you're using overlays, watch out for default initializations.
   For example, if a record type has default initial values for some
   or all of its components, an address clause does not inhibit the
   initialization unless the object is imported.  The same area of memory
   could be initialized twice if you're not careful.
 
3. If you're translating Fortran code to Ada (let's not get into
   whether this is a good idea), and the Fortran uses EQUIVALENCE, you
   should determine just how it's being used.  If the closest semantic
   match to the particular usage of the EQUIVALENCE happens to be
   Unchecked_Conversion, use Unchecked_Conversion.  This requires some
   thought and analysis, which is why automated translation from one high
   level language to another is impractical given the current state of
   the art.
 
Just saying that a Fortran EQUIVALENCE should be translated into an Ada
overlay misses some very important points.
 
> Keith try this excercise. Consider a case in which we are trying to model
> a Fortran EQUIVALENCE statement that maps a big 2D array into a big 1D
> array.
>
> Now write the EXACT code using UC and address overlays for this problem,
> and we will look at what you come up with. I am willing to bet that if
> you write reasonable code in both cases, we will find that
>
> (a) neither is guaranteed to work portably by the RM
> (b) in practice both will work fine with any reasonable implementation

No bet; you're probably right.  In particular, if the objects being
overlaid are large arrays, it probably doesn't make much difference
whether they're declared aliased or volatile, since they're not likely to
be stored temporarily in registers.  Given today's hardware and software,
that is.  (Unless you're on a Cray or Cray-like machine, and the arrays
or parts of them are stored in some kind of vector registers, maybe.)
 
> It pays to get out of pedantic mode when you are dealing with chapter
> 13 in real life. In porting millions of lines of code to GNAT, we have
> found that real code is full of stuff which is definitely NOT guaranteed
> to work by the RM, but we still work to have GNAT accept it properly and
> process it as expected. The minimum guarantees of the RM are so thin as
> to be pretty uninteresting except for the purpose of writing ACVC tests.
 
Ok, but the authors of other compilers may have looked at a different set
of millions of lines of code than you did.  It may be difficult to write
portable code that uses the features of chapter 13, but it's worth trying.

By the way, I plead guilty to the charge of pedantry, and I intend to
continue being annoyingly pedantic.  It's a dirty job, but somebody's
got to do it.  8-)}

-- 
Keith Thompson (The_Other_Keith) kst@sd.aonix.com <http://www.aonix.com> <*>
TeleSo^H^H^H^H^H^H Alsy^H^H^H^H Thomson Softw^H^H^H^H^H^H^H^H^H^H^H^H^H Aonix
5040 Shoreham Place, San Diego, CA, USA, 92122-5989
"Humor is such a subjective thing." -- Cartagia