From: mheaney@ni.net (Matthew Heaney)
Subject: Re: Fortran's Equivalence
Date: 1997/04/08
Date: 1997-04-08T00:00:00+00:00 [thread overview]
Message-ID: <mheaney-ya023680000804971958130001@news.ni.net> (raw)
In-Reply-To: 1997Apr8.155111.26714@nosc.mil
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
next prev parent reply other threads:[~1997-04-08 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 ` 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-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 ` Charles H. Sampson
1997-04-07 0:00 ` Keith Thompson
1997-04-07 0:00 ` Viqar Abbasi
1997-04-08 0:00 ` Charles H. Sampson
1997-04-08 0:00 ` Matthew Heaney [this message]
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-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-28 0:00 ` Fortran's Equivalence 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