comp.lang.ada
 help / color / mirror / Atom feed
From: kst@sd.aonix.com (Keith Thompson)
Subject: Re: Fortran's Equivalence
Date: 1997/04/01
Date: 1997-04-01T00:00:00+00:00	[thread overview]
Message-ID: <E7xn57.AL4@thomsoft.com> (raw)
In-Reply-To: dewar.859697406@merv


In <dewar.859697406@merv> dewar@merv.cs.nyu.edu (Robert Dewar) writes:
> Actually unchecked conversion can cause copies, which are more easily
> avoided with address overlays. 
> 
> I can imagine no technical justification for your claim that UC is
> safer, let alone infinitely safer, than address overlays. I suspect
> this is just a hold over from Ada 83 thinking, with no good technical
> justification.

If you use Unchecked_Conversion, you know you're getting either a view
or a copy of the operand, wherever the compiler happens to have put it
at the moment.  For an address clause this isn't guaranteed, at least
as far as I can tell from my reading of the RM.

AARM-13.3(12.b) says:

    The validity of a given address depends on the run-time model;
    thus, in order to use Address clauses correctly, one needs intimate
    knowledge of the run-time model.

(Yes, I know that AARM annotations are not part of the standard, but I
believe this one is good advice.)

RM95-13.3(16) says:

    X'Address should produce a useful result if X is an object that is
    aliased or of a by-reference type, or is an entity whose Address
    has been specified.

This implies by omission that there is no requirement for X'Address to
mean anything for an ordinary object.  If you do use address clauses to
implement overlays, be sure to declare all overlaid objects aliased --
something that I don't think has been mentioned in this thread.

Since paragraph 16 is marked as "recommended level of support", it is
mandatory for implementations that (claim to) support Annex C.

Finally, RM95-13.3(19) says:

    If the Address of an object is specified, or it is imported or
    exported, then the implementation should not perform optimizations
    based on assumptions of no aliases.

Again, this is part of the "recommended level of support", and thus
is mandatory if Annex C is supported.  However, it's not clear that it
applies to objects whose address is queried rather than specified.

More concretely, assume the following declarations:

    Obj_1 : Some_Type;
    Obj_2 : Some_Other_Type_Of_The_Same_Size_And_Alignment;
    for Obj_2'Address use Obj_1'Address;

(An important point: an overlay can fail badly if the specified address
doesn't satisfy the alignment requirements of the object.)

If Obj_1 and Obj_2 are not declared aliased, I see no guarantee in the
RM that an assignment to Obj_1 will necessarily be reflected in the
value of Obj_2.

I'd like to think that if all the overlaid objects are declared aliased,
everything will work properly, but I can't find a guarantee of this in
the RM (which is no indication that it isn't there).

The discussion of distinct access paths in RM95-6.2(12) seems nearly
relevant, but it applies only to formal parameters.

The nearest Ada equivalent of Fortran's "EQUIVALENCE" is an address
clause overlay (or possibly Unchecked_Union if your compiler supports
this implementation-defined pragma).  However, what you should use
when porting Fortran code to Ada depends on how it's used in Fortran.
If Unchecked_Conversion make more sense, use it.  Try asking yourself
what the Fortran author would have used if the language provided both
EQUIVALENCE and Unchecked_Conversion.

-- 
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




  reply	other threads:[~1997-04-01  0:00 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1997-03-25  0:00 Fortran's Equivalence Viqar Abbasi
1997-03-26  0:00 ` FORTRAN's Equivalence Nick Roberts
1997-03-26  0:00 ` Fortran's Equivalence Robert Dewar
1997-03-26  0:00   ` Robert A Duff
1997-03-29  0:00   ` Matthew Heaney
1997-03-29  0:00     ` Robert Dewar
1997-04-02  0:00       ` JP Thornley
1997-03-26  0:00 ` Tom Moran
1997-03-26  0:00 ` Michael F Brenner
1997-03-26  0:00   ` Larry Kilgallen
1997-03-28  0:00   ` Oliver Kellogg
1997-03-29  0:00   ` Matthew Heaney
1997-03-29  0:00     ` Robert Dewar
1997-04-01  0:00       ` Keith Thompson [this message]
1997-04-01  0:00         ` Robert Dewar
1997-04-01  0:00           ` Robert A Duff
1997-04-01  0:00             ` Robert Dewar
1997-04-04  0:00           ` Keith Thompson
1997-04-04  0:00             ` Keith Thompson
1997-04-04  0:00               ` Robert Dewar
1997-04-08  0:00                 ` Keith Thompson
1997-04-04  0:00             ` Robert Dewar
1997-04-07  0:00               ` Viqar Abbasi
1997-04-08  0:00                 ` Charles H. Sampson
1997-04-08  0:00                   ` Matthew Heaney
1997-04-09  0:00                     ` Stephen Leake
1997-04-09  0:00                       ` Robert Dewar
1997-04-10  0:00                         ` Simon Wright
1997-04-10  0:00                           ` Robert Dewar
1997-04-08  0:00                   ` Robert Dewar
     [not found]                     ` <1997Apr15.163103.27481@nosc.mil>
1997-04-16  0:00                       ` Robert Dewar
1997-04-07  0:00               ` Charles H. Sampson
1997-04-07  0:00               ` Keith Thompson
1997-04-07  0:00             ` Charles H. Sampson
1997-03-29  0:00     ` Robert Dewar
1997-03-28  0:00 ` Charles H. Sampson
1997-03-29  0:00   ` Matthew Heaney
1997-04-01  0:00     ` Charles H. Sampson
1997-03-29  0:00 ` Matthew Heaney
1997-03-29  0:00   ` Robert Dewar
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox