comp.lang.ada
 help / color / mirror / Atom feed
From: sampson@nosc.mil (Charles H. Sampson)
Subject: Re: Fortran's Equivalence
Date: 1997/03/28
Date: 1997-03-28T00:00:00+00:00	[thread overview]
Message-ID: <1997Mar28.170935.19124@nosc.mil> (raw)
In-Reply-To: 333840D1.7B12@cae.ca


In article <333840D1.7B12@cae.ca>, Viqar Abbasi  <viqar@cae.ca> wrote:
>Hi all...
>
>Can anyone tell me the "standard" way to implement Fortran's 
>"EQUIVALENCE" in ADA?  Okay, okay, I realize that this is not really 
>something that should be used in Fortran (or ADA) anyway.  Still, I need 
>to do something as follows:
>
>I have a BIT_PATTERN : System.Unsigned_32.  The first 4 bits represent 
>an integer A, the next 17 represent another record B, the last eleven 
>represent an integer C.  Ada gives something beautiful, in the "use at" 
>clause, which lets me define a record to superimpose onto the bit 
>pattern.  The big problem with this approach is that it isn't 
>guaranteed by the LRM, and I need my application to be portable to 
>other Ada implementations.  The Ada Quality and Style Guide, Clause 
>5.9.4, also tells us that we should not use the "use at" clause to do 
>such things.  I am using the GNAT compiler, 3.07 on the SGI.  The final 
>system will be delivered for a VAX.
>
>I have started doing my mapping via "Unchecked Conversions".  This seems 
>to be going well, as long as I take care of the VAX/SGI bit-pattern 
>differences.  Would using Unchecked_Conversions, when the sizes are 
>always the same, be considered 100% portable, and will work under any 
>ADA implementation?
>
> ...

     It looks to me like you might not have a true overlaying problem 
here.  As I understand what you've written, you have a 32-bit variable 
(unnamed, presumably INTEGER).  For simplicity, I'll refer to that vari-
able as R.  Using FORTRAN's EQUIVALENCE statement you have placed your 
A, B, and C, in sequence, on top of R.  The question is, what are you 
doing with R?  Are you using it numerically (adding, multiplying, etc.) 
or are you just assigning it to and from similar values.  If the latter, 
then what you have is a FORTRAN kludge to create a record.  In such a 
case, an Ada record type declaration with accompanying representation 
clause is just what you want.  There are some portability problems with 
this but they can be minimized, although the source code is not pretty.

     I think you've been led astray by the reference to "the FORTRAN 
'equivalence' feature" in section 5.9.4 of the style guide.  This sec-
tion is referring to address clauses, which are of the form

                        for Pdq use at ...

These are quite different from the record representation clause, which 
doesn't use the reserved word "at".  This guideline is prohibiting such 
things as

                        for Xyz use at Pdq;

to "overlay" Xyz and Pdq.  This is more than just a style issue.  This 
misuse of the address clause creates an erroneous program, whose behav-
ior might not be at all what you expect and can vary wildly from one 
compiler to another.

     Unchecked_conversion should be used when you absolutely have to and 
avoided in all other circumstances.  It is definitely not portable.  The 
only thing I can say about the way you're using it is that it will 
probably be accepted by most compilers.  Whether those compilers will do 
what you want or not, I don't know.  One of the many nice things about 
Ada is that when you must use unchecked conversions they're hanging out 
there in the source code for the world to see.  As a result, when you 
port it's easy to search them out and make sure they're behaving prop-
erly in the new environment.

				Charlie




  parent reply	other threads:[~1997-03-28  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 ` 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 ` FORTRAN's Equivalence Nick Roberts
1997-03-26  0:00 ` Fortran's Equivalence 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
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                   ` Robert Dewar
     [not found]                     ` <1997Apr15.163103.27481@nosc.mil>
1997-04-16  0:00                       ` Robert Dewar
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-07  0:00               ` Keith Thompson
1997-04-07  0:00               ` Charles H. Sampson
1997-04-07  0:00             ` Charles H. Sampson
1997-03-29  0:00     ` Robert Dewar
1997-03-26  0:00 ` Tom Moran
1997-03-28  0:00 ` Charles H. Sampson [this message]
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