Fortran's Equivalence

Fortran's Equivalence

[Viqar Abbasi]

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?

Furthermore, are any of you aware of a better way to map variables on 
top of each other?  Please consider in any reply that I have extremely 
tight speed requirements as well.

Thank you kindly,
Viqar

Re: Fortran's Equivalence

[Robert Dewar]

Vigar says

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

Isn't it amazing how Ada's concentration on precision sometimes works to
its disadvantage :-)

Here we have a case where someone is used to misusing a construct in Fortran
(EQUIVALENCE) to do something highly non-portable (go look at the Fortran
standard with the same care that you have looked at the Ada standard!)

Sure the RM does not "guarantee" anything here, because it has very little
to say about representation, but if you are doing low level mucking around
the use of "use at" is exactly equivalent to Fortran EQUIVALENCE, and there
is no reason to be shy of it.

The statement in the AQ&S is a holdover from Ada 83 days, and I see no
justification for it. If "use at" does what you want, use it!

Re: Fortran's Equivalence

[Robert A Duff]

In article <dewar.859383980@merv>, Robert Dewar <dewar@merv.cs.nyu.edu> wrote:
>justification for it. If "use at" does what you want, use it!

But you might want to spell it using the preferred Ada 95 syntax:
"for X'Address use ...;".

(The original poster did he's using an Ada 95 compiler, right?)

- Bob

Re: Fortran's Equivalence

[Matthew Heaney]

In article <dewar.859383980@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) wrote:

>Vigar says
>
><<
>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.>>
>

>The statement in the AQ&S is a holdover from Ada 83 days, and I see no
>justification for it. If "use at" does what you want, use it!

This is bad advice Robert.  The use of Unchecked_Conversion is clearly what
is required.

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
<mailto:matthew_heaney@acm.org>
(818) 985-1271

Re: Fortran's Equivalence

[Robert Dewar]

iMatthew Heaney says

<<This is bad advice Robert.  The use of Unchecked_Conversion is clearly what
is required.>>

In response to my encouragement to use address clauses for overlay where
that is convenient.

Matthew, interesting opinion ... but not so interesting if you don't give
some backup to your claim. 

First, I trust you realize that the negative view of overlap expressed
in the Ada 83 RM is COMPLETELY GONE in Ada 95. In the RM there is absolutely
no preference for the use of unchecked conversion over the use of address
overlays. You should use whichever of the two is more convenient.

Second, as you can see from the subject, the issue is mimicking the Fortran
equivalence statement. Address overlays are a very close semantic match
for equivalence, so it makes sense to answer the question this way.

I am curious to wait for the justification you have for the above opinion!

Re: Fortran's Equivalence

[JP Thornley]

In article: <dewar.859697187@merv>  dewar@merv.cs.nyu.edu (Robert Dewar) 
writes:
> ...............................  In the RM there is absolutely
> no preference for the use of unchecked conversion over the use of 
address
> overlays. You should use whichever of the two is more convenient.

Whichever is used it must be important to show that writing a valid 
value in one type cannot result in a read of an invalid value of the 
other - and in general this will be easier if Unchecked_Conversion 
(which is strictly one-way) is used rather than overlays.

Am I right in feeling that 13.9.1(14) applies to both (even though it is 
only a note)?

Phil Thornley

-- 
------------------------------------------------------------------------
| JP Thornley    EMail jpt@diphi.demon.co.uk                           |
|                      phil.thornley@acm.org                           |
------------------------------------------------------------------------

Re: FORTRAN's Equivalence

[Nick Roberts]

Viqar Abbasi <viqar@cae.ca> wrote in article <333840D1.7B12@cae.ca>...

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

Robert Duff (circa this thread) is right, in that you should use the for
X'Address clause preferred in Ada 95.

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

You should not use Unchecked_Conversion, you should use the method you
suggested above. Don't worry about whether the technique you use is
portable or not. It will not be, and does not need to be. All you need to
do is to ISOLATE the non-portable bit (in a subprogram or package). Ensure
that the interface to this module is well defined. Then, all you have to do
to port to a new compiler or target is to change the isolated module.
Everything else remains untouched, and (provided the tenets of the
interface are not violated) its operation remains guaranteed.

> Furthermore, are any of you aware of a better way to map variables on 
> top of each other?  Please consider in any reply that I have extremely 
> tight speed requirements as well.

Why do you need to do this? There may well be a better way to achieve
whatever you need to do.

Hope this helps. Nick.

Re: Fortran's Equivalence

[Michael F Brenner]

The requirements for poratability and speed might be opposing each other
a little, and some balance might be required. One possible compromise is
to use the Ada 95 SHIFT capababilities. To get at a bit string, shift it
and AND it, similar to what the FORTRAN generated code is doing in this
case. You are right, however, that address overlays are almost always
faster in execution time than any operation in a HOL, unless the HOL
optimizes the operation away. The portability problem comes in because
the Ada-95 manual did not standardize a bit numbering in the word, nor
does it standardize a pragma to tell which bit is zero in a portable
manner. Had it done so, then about half of all bit field applications
would have been portable using address overlays. As it is, true
portability (without a changing global flag telling where bit one is), is
difficult to accomplish without using specific operations (like SHIFT),
which have effects on performance (both speed and logically overspecified
algorithms). 

Re: Fortran's Equivalence

[Larry Kilgallen]

In article <5hbcdn$i1h@top.mitre.org>, mfb@mbunix.mitre.org (Michael F Brenner) writes:

> manner. Had it done so, then about half of all bit field applications
> would have been portable using address overlays. As it is, true
> portability (without a changing global flag telling where bit one is), is
> difficult to accomplish without using specific operations (like SHIFT),
> which have effects on performance (both speed and logically overspecified
> algorithms). 

But each compiler knows which end is up and has enough information
to optimize away shifts done only for the sake of addressing this
issue.  For instance, many machines have a more efficient set of
instructions for testing bit 3 (from whichever end) without actually
shifting it to the end of a register.

Larry Kilgallen

Re: Fortran's Equivalence

[Oliver Kellogg]

Michael F Brenner (mfb@mbunix.mitre.org) wrote:
> [...]                         The portability problem comes in because
> the Ada-95 manual did not standardize a bit numbering in the word, nor
> does it standardize a pragma to tell which bit is zero in a portable
> manner. 

Portability is nevertheless not impossible, just more difficult to
achieve. For porting code between a host computer and a 1750A target, we
wrote following package:

-- package Bitranges, 1750A version

with System;

package Bitranges is    -- MIL-STD-1750A version

  Unit : constant := System.Storage_Unit;

  subtype Bit_00_00 is Natural range 15..15;
  subtype Bit_00_01 is Natural range 14..15;
  subtype Bit_00_02 is Natural range 13..15;
  subtype Bit_00_03 is Natural range 12..15;
  subtype Bit_00_04 is Natural range 11..15;
  subtype Bit_00_05 is Natural range 10..15;
  subtype Bit_00_06 is Natural range 09..15;
  subtype Bit_00_07 is Natural range 08..15;
  subtype Bit_00_08 is Natural range 07..15;
  subtype Bit_00_09 is Natural range 06..15;
  subtype Bit_00_10 is Natural range 05..15;
  subtype Bit_00_11 is Natural range 04..15;
  subtype Bit_00_12 is Natural range 03..15;
  subtype Bit_00_13 is Natural range 02..15;
  subtype Bit_00_14 is Natural range 01..15;
  subtype Bit_00_15 is Natural range 00..15;

  subtype Bit_01_01 is Natural range 14..14;
  subtype Bit_01_02 is Natural range 13..14;
  subtype Bit_01_03 is Natural range 12..14;
  subtype Bit_01_04 is Natural range 11..14;
  [...]
  subtype Bit_01_14 is Natural range 01..14;
  subtype Bit_01_15 is Natural range 00..14;

  subtype Bit_02_02 is Natural range 13..13;
  subtype Bit_02_03 is Natural range 12..13;
  [...]
  subtype Bit_02_15 is Natural range 00..13;

  [...]

  subtype Bit_14_14 is Natural range 01..01;
  subtype Bit_14_15 is Natural range 00..01;

  subtype Bit_15_15 is Natural range 00..00;

end Bitranges;


-- Package bitranges spec, host computer version

with System;

package Bitranges is    -- host computer native version

  Unit : constant := System.Storage_Unit;

  subtype Bit_00_00 is Natural range 00..00;
  subtype Bit_00_01 is Natural range 00..01;
  subtype Bit_00_02 is Natural range 00..02;

  [...]

  subtype Bit_15_15 is Natural range 15..15;

end Bitranges;


-- Representation clauses must then be written e.g. as follows:

with Bitranges;  use Bitranges;

package Example is

  type My_Rec is record
    A : Short_Integer;
    B : Short_Integer;
  end My_Rec;

  for My_Rec use record
    A  at 0*Unit range Bit_00_01'first..Bit_00_01'last;
    B  at 0*Unit range Bit_02_15'first..Bit_02_15'last;
  end record;

end Example;

Re: Fortran's Equivalence

[Matthew Heaney]

In article <5hbcdn$i1h@top.mitre.org>, mfb@mbunix.mitre.org (Michael F
Brenner) wrote:

>The requirements for poratability and speed might be opposing each other
>a little, and some balance might be required. One possible compromise is
>to use the Ada 95 SHIFT capababilities.

No.  Do not use shift - use a record with a representation clause, and
convert it using Unchecked_Conversion.  Using shift is for languages that
lack Ada's powerful abstraction features.  (Even in C you can do use a bit
field.)

>To get at a bit string, shift it
>and AND it, similar to what the FORTRAN generated code is doing in this
>case. You are right, however, that address overlays are almost always
>faster in execution time than any operation in a HOL, unless the HOL
>optimizes the operation away.

Using Unchecked_Conversion will very likely generate NO code, and it's
infinately safer than an address overlay.

People have been making claims about "HOL inefficiency" since the first
compilers came out 40 years ago.  How do you know, because greater semantic
information is available to the Ada compiler, that equivalent structures
aren't more efficient in Ada (proudly HOL) than in a lower-level language?

>The portability problem comes in because
>the Ada-95 manual did not standardize a bit numbering in the word, nor
>does it standardize a pragma to tell which bit is zero in a portable
>manner. Had it done so, then about half of all bit field applications
>would have been portable using address overlays. As it is, true
>portability (without a changing global flag telling where bit one is), is
>difficult to accomplish without using specific operations (like SHIFT),
>which have effects on performance (both speed and logically overspecified
>algorithms). 

What's wrong with the Bit_Order attribute?  Can't you use that to portably
specify record representations?

It's all very theoretically interesting about what would have allowed
portability using overlays, but since you should never use address overlays
to change representation, then such conversation is just idle speculation,
eh?

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
<mailto:matthew_heaney@acm.org>
(818) 985-1271

Re: Fortran's Equivalence

[Robert Dewar]

Matthew Heaney says

<<It's all very theoretically interesting about what would have allowed
portability using overlays, but since you should never use address overlays
to change representation>>

Well Matthew certainly seems to be announcing lots of moral principles
tonight :-) But once again, no technical justification.

The use of address overlays to achieve a chnage of representation is a 
perfectly legitimate tool in the Ada 95 arsenal, which is rarely used, but
can be quite useful when it does apply, and can often be considerably
more convenient than the use of unchecked conversion, and no less portable.

Re: Fortran's Equivalence

[Robert Dewar]

iMatthew Heaney said

<<Using Unchecked_Conversion will very likely generate NO code, and it's
infinately safer than an address overlay.>>

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.

Re: Fortran's Equivalence

[Keith Thompson]

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

Re: Fortran's Equivalence

[Robert Dewar]

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.

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

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.

Re: Fortran's Equivalence

[Robert A Duff]

In article <dewar.859897867@merv>, Robert Dewar <dewar@merv.cs.nyu.edu> wrote:
>It pays to get out of pedantic mode when you are dealing with chapter
>13 in real life. ...

May I quote you on that during the next ARG meeting?  ;-)

- Bob

Re: Fortran's Equivalence

[Robert Dewar]

<<May I quote you on that during the next ARG meeting?  ;>>

Hmmmm! I don't think so :-)
seriously, chapter 13 in the RM, like the rest of the RM, *has* to take
a pedantic, or we should rather say, formal, view of things!

Re: Fortran's Equivalence

[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

Re: Fortran's Equivalence

[Robert Dewar]

Keith said

<<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-)}).>>

There is no particular point in declaring these objects aliased, unless you
intend to take their address or take a pointer to them. I suppose there
might be some compilers where the use of aliased would make a difference
in optimization in the absence of pointers, but you certainly cannot deduce
this from the RM (in either informal or pedantic mode). Also aliased may
well have the effect of adding additional "dope
" information which you may or may not want.

Declaring the two variables to be volatile *does* make good sense. This
ensures that references always go to memory, and almost certainly must
disconnect any optimizations that would defeat the non-pointer based
aliasing.

Note incidentally one HUGE advantage of overlays over the use of
unchecked conversion, which is that if you use uncheckd conversion,
you always have to do two of them to make a modification. Consider
a case where we want an array of 32-bit integers overlaid by an
array of 32-bit floats.

Now if you do this by declaring an array of 32-bit floats and then
doing unchecked conversion to 32-bit integer, you will end up doing

    x(J) := To_Float_32 (Fiddle (To_Integer_32 (x(J))));

which is MUCH more more inpenetrable than:

    x_Int (J) := Fiddle (X_Int (J));

Of course it is always a matter of taste whether you want to emphasize
the nature of what you are doing by writing the explicit stuff each
time. A legitimate objection to the second form here might be that
it is TOO easy to write and read!

Re: Fortran's Equivalence

[Keith Thompson]

In <dewar.860159911@merv> dewar@merv.cs.nyu.edu (Robert Dewar) writes:
> Keith said
> 
> <<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-)}).>>
> 
> There is no particular point in declaring these objects aliased, unless you
> intend to take their address or take a pointer to them.
[...]

To get the overlay in the first place, you have to take the address of
at least one of the objects (unless you use some other ugly trick):

    Obj1 : Some_Type;
    ...
    Obj2 : Some_Other_Type_With_Compatible_Size_And_Alignment;
    for Obj2'Address use Obj1'Address;

So at least Obj1 should be declared aliased, right?

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

Re: Fortran's Equivalence

[Charles H. Sampson]

In article <dewar.860159911@merv>, Robert Dewar <dewar@merv.cs.nyu.edu> wrote:

>Note incidentally one HUGE advantage of overlays over the use of
>unchecked conversion, which is that if you use uncheckd conversion,
>you always have to do two of them to make a modification. Consider
>a case where we want an array of 32-bit integers overlaid by an
>array of 32-bit floats.
>
>Now if you do this by declaring an array of 32-bit floats and then
>doing unchecked conversion to 32-bit integer, you will end up doing
>
>    x(J) := To_Float_32 (Fiddle (To_Integer_32 (x(J))));
>
>which is MUCH more more inpenetrable than:
>
>    x_Int (J) := Fiddle (X_Int (J));
>
>Of course it is always a matter of taste whether you want to emphasize
>the nature of what you are doing by writing the explicit stuff each
>time. A legitimate objection to the second form here might be that
>it is TOO easy to write and read!

     I would be one of the objectors, except that I would characterize 
it as not easy to read.  The wordy form above says pretty clearly what's 
going on: Take the bits that make up the value of x(j), treat them as a 
32-bit integer, fiddle with the result, treat those bits as a floating-
point value, and assign them to x(j).  None of that information is imme-
diately available in the shorted version.  It lacks an attribute that I 
call "local understandability".

				Charlie

Re: Fortran's Equivalence

[Viqar Abbasi]

Hi, from the original poster... :)

I've appreciated this dicussion on the "best" way to implement overlays. 
One thing that I forgot to mention was that I am confined to the Ada 83 
environment, regardless of platform.  So, I am attempting a conscious 
effort to enforce "old-style Ada 83 thinking".

My original reason for this post was because when I received the code, 
it used address clause overlays.  However, on my GNAT 3.07 for SGI, the 
overlaying didn't work (or at least, that particular code have the 
wrong results).  So, I added a routine for bit swapping, (localizing the 
effect of changing machines to that one small routine), and then 
proceeded with Unchecked_Conversion.  Later, when I downloaded GNAT 
3.09, I found that it offered a whole new spectrum of address clause 
flexibility.  A quick test showed me that the old address clause overlay 
would work.  So, I thought I'd ask about the "preferred method" to do 
something which I knew is dangerous.  (And actually, I've never used 
EQUIVALENCE in a Fortran program... But I knew about it. :)

<< there's the Prologue :) >>

<< Questions (this should be a standardized form) >>

Can someone please explain to me the effect of representation clauses 
when doing these overlays?  For example,

record My_Record is
    A:  some_type;
    B:  some_other_type;
    C:  still_another_type;
end record;
for My_Record_Type'Size use 32;
for My_Record_Type use
  record
    A at 0 range 0 .. 14;
    B at 0 range 15 .. 24;
    C at 0 range 25 .. 31;
  end record;

Does "range 0 .. 14" mean the Most Signicant Bits?  Or does it mean 
"Left most bits"?  This will clearly have an impact on my overlays.  If 
I'm going to move bits arouund, then I don't want to have to change the 
record representation clauses...  Will I be able to avoid it, by 
only changing my bit-manipulation routine, depending on my machine?

Thanks for being here... :)
V.

Re: Fortran's Equivalence

[Charles H. Sampson]

In article <3349165C.3B93@cae.ca>, Viqar Abbasi  <viqar@cae.ca> wrote:
> ...
>
>My original reason for this post was because when I received the code, 
>it used address clause overlays.  However, on my GNAT 3.07 for SGI, the 
>overlaying didn't work (or at least, that particular code have the 
>wrong results).  So, I added a routine for bit swapping, (localizing the 
>effect of changing machines to that one small routine), and then 
>proceeded with Unchecked_Conversion.  Later, when I downloaded GNAT 
>3.09, I found that it offered a whole new spectrum of address clause 
>flexibility.  A quick test showed me that the old address clause overlay 
>would work.  So, I thought I'd ask about the "preferred method" to do 
>something which I knew is dangerous.  (And actually, I've never used 
>EQUIVALENCE in a Fortran program... But I knew about it. :)
>
     Great!  An actual example of my repeated claim that the behavior 
of erroneous constructs can change from one version of a compiler to the 
next.  Admittedly, from your point of view this change was an improve-
ment, but it was a change nonetheless.
>
>record My_Record is
>    A:  some_type;
>    B:  some_other_type;
>    C:  still_another_type;
>end record;
>for My_Record_Type'Size use 32;
>for My_Record_Type use
>  record
>    A at 0 range 0 .. 14;
>    B at 0 range 15 .. 24;
>    C at 0 range 25 .. 31;
>  end record;
>
>Does "range 0 .. 14" mean the Most Signicant Bits?  Or does it mean 
>"Left most bits"?  This will clearly have an impact on my overlays.  If 
>I'm going to move bits arouund, then I don't want to have to change the 
>record representation clauses...  Will I be able to avoid it, by 
>only changing my bit-manipulation routine, depending on my machine?

     The bit order depends on the compiler.  If you want to do the ex-
tra work, you can code your record representation clauses to depend on 
one or more constant objects which you then set to appropriate values 
when transporting.

				Charlie

Re: Fortran's Equivalence

[Matthew Heaney]

In article <1997Apr8.155111.26714@nosc.mil>, sampson@nosc.mil (Charles H.
Sampson) wrote:


>>record My_Record is
>>    A:  some_type;
>>    B:  some_other_type;
>>    C:  still_another_type;
>>end record;
>>for My_Record_Type'Size use 32;
>>for My_Record_Type use
>>  record
>>    A at 0 range 0 .. 14;
>>    B at 0 range 15 .. 24;
>>    C at 0 range 25 .. 31;
>>  end record;
>>
>>Does "range 0 .. 14" mean the Most Signicant Bits?  Or does it mean 
>>"Left most bits"?  This will clearly have an impact on my overlays.  If 
>>I'm going to move bits arouund, then I don't want to have to change the 
>>record representation clauses...  Will I be able to avoid it, by 
>>only changing my bit-manipulation routine, depending on my machine?
>
>     The bit order depends on the compiler.  If you want to do the ex-
>tra work, you can code your record representation clauses to depend on 
>one or more constant objects which you then set to appropriate values 
>when transporting.

True, "default" bit order depends on the compiler.  But for a record
representation clause, Ada 95 allows the programmer to specify how to
interpret the bit order via the 'Bit_Order attribute definition clause.

for My_Record_Type'Bit_Order use Low_Order_First;

means that component A occupies the least significant portion of the 32
bits of storage.   See RM95 13.5.3.

Sadly, I don't think there's a way to specify order of array elements.  For
example, if I had a packed array of bits, I'd like the zero'th bit to
always mean the bit located in the least significant bit of the storage. 
Right now, if I'm on a big endian machine, then bit 0 is the most
significant.  A bit of a pain, because I have to calculate the index of the
array element I really want (O'Last - Index).  I wish there were an
attribute for arrays too, instead of just for records.

Matt

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
<mailto:matthew_heaney@acm.org>
(818) 985-1271

Re: Fortran's Equivalence

[Stephen Leake]

Matthew Heaney wrote:
> 
> True, "default" bit order depends on the compiler.  But for a record
> representation clause, Ada 95 allows the programmer to specify how to
> interpret the bit order via the 'Bit_Order attribute definition clause.
> 
> for My_Record_Type'Bit_Order use Low_Order_First;
> 
> means that component A occupies the least significant portion of the 32
> bits of storage.   See RM95 13.5.3.

Unfortunately, not even gnat implements this attribute!

-- 
- Stephe

Re: Fortran's Equivalence

[Robert Dewar]

Stephen says

<<Unfortunately, not even gnat implements this attribute>>

referring to the Bit_Order attribute representation clause.

Well i appreciate the implied expectation that GNAT implemnts everything :-)

But the Ada 95 language does not really expect this attribute definitoin
to be implemented for byte addressed machines, since it results in very
awkward non-contiguous fields.

Re: Fortran's Equivalence

[Simon Wright]

dewar@merv.cs.nyu.edu (Robert Dewar) writes:

> Stephen says
> 
> <<Unfortunately, not even gnat implements this attribute>>
> 
> referring to the Bit_Order attribute representation clause.
> 
> Well i appreciate the implied expectation that GNAT implemnts everything :-)
> 
> But the Ada 95 language does not really expect this attribute definitoin
> to be implemented for byte addressed machines, since it results in very
> awkward non-contiguous fields.

What worked for me was

  given an interfaces.c.int to be interpreted as bit fields
  declare record type without representation
  declare variable "result" of this type
  if system.default_bit_order = system.high_order_first then
    declare derived record type with big-endian representation
    do unchecked conversion from interfaces.c.int to this type
    assign to "result"
  else
    declare derived record type with little-endian representation
    do unchecked conversion from interfaces.c.int to this type
    assign to "result"
  end if

which is long-winded but does the job! No doubt there are other ways ..

-Simon

Re: Fortran's Equivalence

[Robert Dewar]

Simon said

<<What worked for me was

  given an interfaces.c.int to be interpreted as bit fields
  declare record type without representation
  declare variable "result" of this type
  if system.default_bit_order = system.high_order_first then
    declare derived record type with big-endian representation
    do unchecked conversion from interfaces.c.int to this type
    assign to "result"
  else
    declare derived record type with little-endian representation
    do unchecked conversion from interfaces.c.int to this type
    assign to "result"
  end if

which is long-winded but does the job! No doubt there are other ways ..>>


This does NOT work in the general case, it only works if you have a simple
case where all fields are conveniently aligned, which is a small subset of
possible cases.

Re: Fortran's Equivalence

[Robert Dewar]

Charles says

<<     Great!  An actual example of my repeated claim that the behavior
of erroneous constructs can change from one version of a compiler to the
next.  Admittedly, from your point of view this change was an improve-
ment, but it was a change nonetheless.>>

I don't get it -- everyone knows this is true, who are you arguing with,
no one even implied the contrary! You did say that you preferred overlays
to be erroneous rather than implementation defined, but the above para
has nothing to do with that issue.

Re: Fortran's Equivalence

[Robert Dewar]

Charles said

<<     This meant more to me than it might to others.  Often when I say
that the "semantics" of an erroneous construct can change from one ver-
sion of a compiler to the next I'm told that no serious compiler would
do such a thing; its maintainers would know that users might have come
to rely on the current behavior>>

OK, so, as I noted, no one in *this* thread made a silly statement like
this (that the behavior would not change from version to version). It
is always confusing when you are refuting statements that have not been
visibly made from things that "you are told" by persons or persons unknown
who are clearly wrong :-)

Re: Fortran's Equivalence

[Keith Thompson]

In <E8385t.9zE@thomsoft.com> I pontificated:
[...]
> 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-)}).
[...]

In an article that I either forgot having read or never saw in the first
place, Robert Dewar did suggest using pragma Volatile on overloaded
objects.

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

Re: Fortran's Equivalence

[Robert Dewar]

Keith said

<<In an article that I either forgot having read or never saw in the first
place, Robert Dewar did suggest using pragma Volatile on overloaded
objects.>>

meaning of course overlaid objects. Currently objects cannot be overloaded
in Ada -- perhaps if such are introduced in the future we might want to
make them Volatile, in the hope that they would go away again :-) :-)

Re: Fortran's Equivalence

[Keith Thompson]

In <dewar.860184715@merv> dewar@merv.cs.nyu.edu (Robert Dewar) writes:
> Keith said
> 
> <<In an article that I either forgot having read or never saw in the first
> place, Robert Dewar did suggest using pragma Volatile on overloaded
> objects.>>
> 
> meaning of course overlaid objects. Currently objects cannot be overloaded
> in Ada -- perhaps if such are introduced in the future we might want to
> make them Volatile, in the hope that they would go away again :-) :-)

Yeah, that's what I meant.  I always did have trouble with the pluperfect
subjunctive.  (Insert Boston cabbie joke here.)

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

Re: Fortran's Equivalence

[Charles H. Sampson]

In article <E8385t.9zE@thomsoft.com>, Keith Thompson <kst@sd.aonix.com> wrote:
> 
>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.
> 
     From something I've recently learned in another thread, I gather 
that such a program would be erroneous according to 13.3(13).  Appar-
ently it's o. k. to interpret the initializations as making the address 
invalid.

>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.
> 
     Bless you, Keith.  This is very close to a point I've been trying 
to make in the CMS-2 world for years.  If you want to translate an over-
lay into Ada it's necessary to understand how the overlay is being used.  
The CMS-2 to Ada translator that I was responsible for was very conser-
vative; it refused to translate overlays at all, calling for user inter-
vention.  Unfortunately, users of CMS-2 translators want the translator 
to handle overlays.  They're all over the place and typically very dif-
ficult to figure out.  The result was that our translator would regu-
larly lose out to others that claimed to translate overlays by one or 
another simplistic approach.

     If development money had held out we intended to detect some com-
mon cases that were translatable.  And if cows had wings ...

				Charlie

Re: Fortran's Equivalence

[Tom Moran]

>  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. 
  I assume there's some reason you couldn't make Bit_Pattern a record
and use a representation clause to specify that A is in the first 4
bits, etc?  
  Regardless of how you do things, I trust you've considered the
portability problems of 'endedness'.

Re: Fortran's Equivalence

[Charles H. Sampson]

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

Re: Fortran's Equivalence

[Matthew Heaney]

In article <1997Mar28.170935.19124@nosc.mil>, sampson@nosc.mil (Charles H.
Sampson) wrote:


>     Unchecked_conversion should be used when you absolutely have to and 
>avoided in all other circumstances.  It is definitely not portable.

What is non-portable about using Unchecked_Conversion to convert an integer
to a record?  The only time you have a portability problem with UC is when
the target type is unconstrained.  Since the target type is constrained,
and can be specified using a portable representation clause,  using UC
seems like the most sensible thing to do.

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
<mailto:matthew_heaney@acm.org>
(818) 985-1271

Re: Fortran's Equivalence

[Charles H. Sampson]

In article <mheaney-ya023680002903971544290001@news.ni.net>,
Matthew Heaney <mheaney@ni.net> wrote:
>In article <1997Mar28.170935.19124@nosc.mil>, sampson@nosc.mil (me) wrote:
>
>>     Unchecked_conversion should be used when you absolutely have to and 
>>avoided in all other circumstances.  It is definitely not portable.
>
>What is non-portable about using Unchecked_Conversion to convert an integer
>to a record?  The only time you have a portability problem with UC is when
>the target type is unconstrained.  Since the target type is constrained,
>and can be specified using a portable representation clause,  using UC
>seems like the most sensible thing to do.

     Whoops!  I've got at least a moderate amount of egg on my face!  As 
well as I can tell, this particular use of Unchecked_Conversion is now 
100% portable.  (I was thinking with a 12-year old mindset.  More about 
that in another post.)  Of course, in general Unchecked_Conversion is 
not portable.

     However, one point of this part of my response was to encourage the 
use of Unchecked_Conversion when it's the right thing to do.  I didn't 
want to look like one of those people who say that it is evil and should 
be avoided at all times.

				Charlie

Re: Fortran's Equivalence

[Matthew Heaney]

In article <333840D1.7B12@cae.ca>, Viqar Abbasi <viqar@cae.ca> wrote:

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

Why wouldn't it be portable?  RM95 13.9 (5 - 10) list the conditions under
which the language guarantees the behavior of Unchecked_Conversion.  Since
your target type is constrained, and the size of the source and target
types are the same, what's non-portable about UC?

The words about the RM recommending to not use "use at" may be referring to
the fact that that form of address overlay clause is an obsolescent feature
of the language; it was replaced by the O'Address form.

Of course, you shouldn't be using address overlays to change representation
anyway, and the RM is rightly admonishing you to not do so.  That what
Unchecked_Conversion is for.

To move data - portably - from a big-endien to a little endien machine, be
sure to use the Bit_Order attribute described in RM95 13.5.3.

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
<mailto:matthew_heaney@acm.org>
(818) 985-1271

Re: Fortran's Equivalence

[Robert Dewar]

iMatthew Heaney says

<<Of course, you shouldn't be using address overlays to change representation
anyway, and the RM is rightly admonishing you to not do so>>

Now I am pretty sure you are reading the Ada 83 RM, there is no such
admonishment in the Ada 95 RM, nor any reason for one. Indeed, the
implementation is encouraged to go out of its way to make overlays
work even without pragma Volatile, although for my taste I prefer to
use pragma Volatile on both variables when address overlays are used.