Re: Representation Clause Bit Ordering

[Peter Hermann <ica2ph@alpha1.csv.ica.uni-stuttgart.de>]

Joe Wisniewski <wisniew@acm.org> wrote:
> OK, those of good long-term memories.... was it in Ada Letters about
> 4-5 years ago, there was a paper written about something very close
> to this issue; or an endian-ness independent approach for rep-specs,
> or something like this???????

I dug out the following:

--snip--snip--snip--snip--snip--snip--snip--snip--snip--snip--snip

From: "Norman H. Cohen" <ncohen@watson.ibm.com>
Newsgroups: comp.lang.ada
Subject: Re: Rep Specs,endian,ncohen
Date: Thu, 10 Oct 1996 12:02:05 -0400
Organization: IBM Thomas J. Watson Research Center
Lines: 83
Message-ID: <325D1DFD.3DE1@watson.ibm.com>
References: <3259589E.1740@smtp.svl.trw.com> <325A510D.14E1@gsfc.nasa.gov> <53g3ag$1otk@info4.rus.uni-stuttgart.de>
Reply-To: ncohen@watson.ibm.com
NNTP-Posting-Host: socks1.watson.ibm.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: Mozilla 3.0 (Win95; I)

Peter Hermann wrote:

> I remember Norman H. Cohen has written an essay about the endian
> /portability problem somewhere in AdaLetters(?).

"Endian-Independent Record Representation Clauses", Ada Letters XIV, No.
1 (January/February 1994), pp. 27-29

Stephen Leake's solution appears to be an instance of the approach
suggested in the article.  The article gives the general recipe for
constructing the component clauses.

Note that the problem being solved here is the porting of the source
text for record-representation clauses, NOT the run-time translation of
a byte stream from one endianness to another.

Please disregard the assertion in the article that this problem would be
solved in Ada 9X by an attribute definition clause for the 'Bit_Order
attribute.  The implementation advice in RM95-13.5.3(8) allows a
compiler to reject an attribute-definition clause for the nondefault bit
order in all the useful cases.  

Compilers are generally allowed to reject nondefault 'Bit_Order
definitions because the designers of Ada 95 believed that component
clauses interpreted according to the nondefault bit order could specify
noncontiguous bit fields, an implementation nightmare.  However, that
depends on how you interpret the meaning of a bit offset in a
nondefault-endian component clause.  If you insist that

   at B range 10 .. 12

be synonymous, assuming 8-bit bytes, with

   at B+1 range 2 .. 4

then you do indeed get noncontiguous bit fields.  But another
interpretation is to look at the highest bit number, say b, specified
with a given byte offset, and to view all component clauses with that
byte offset as specifying a contiguous range of bits within the
smallest  "loadable storage unit" (byte, halfword, word, or doubleword
on a typical 32-bit or 64-bit machine) having at least b+1 bits.  For
example, given the component clauses

   A at 0 range 0 .. 5;
   B at 0 range 6 .. 11;
   C at 0 range 12 .. 15;

and no other "at 0" component clauses, we would assume that A, B, and C
reside within a 16-bit loadable storage unit at offset 0, and that when
this 16-bit field is loaded into a register, B is a contiguous field of
bits somewhere in the middle of this 16-bit unit.  Whether A is at the
high-order end or the low-order end of the 16-bit unit depends on which
bit ordering applies to the record type, but either way, there is a
sensible interpretation with B specifying a field that is contiguous
when loaded.  

Given this interpretation of bit offsets, there is a one-to-one
correspondence between record representation clauses that specify a
given layout when interpreted as big-endian clauses and other record
representation clauses that specify the "same" layout when interpreted
as little-endian representation clauses.  (I explain below what I mean
when I say that layouts are the "same".)  Thus it would be practical to
require all compilers to support nondefault-endian record-representation
clauses, with an attribute-definition clause for T'Bit_Order determining
how the record-representation clause for type T is to be interpreted. 
This would solve the source portability problem by allowing the
programmer to arbitrarily specify a layout in his favorite bit order,
knowing that a compiler that is big-endian by default and a compiler
that is little-endian by default will interpret the
record-representation clause the "same" way.  

When I say that a layout on a big-endian machine and a layout on a
little-endian machine are the "same", I mean that the layout is divided
into "loadable storage units" with the same sizes and byte offsets, and
that the left-to-right bit position of each record component within
corresponding loadable storage units is the same.  These are the only
properties of a layout that can be usefully preserved among
opposite-endian machines.

-- 
Norman H. Cohen
mailto:ncohen@watson.ibm.com
http://www.research.ibm.com/people/n/ncohen