From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,b77305e4038ca5a X-Google-Attributes: gid103376,public From: Peter Hermann Subject: Re: Representation Clause Bit Ordering Date: 1999/09/08 Message-ID: <7r5861$gob$1@infosun2.rus.uni-stuttgart.de> X-Deja-AN: 522455013 References: <37860BA1.CF7E58B2@averstar.com> Organization: Comp.Center (RUS), U of Stuttgart, FRG User-Agent: tin/pre-1.4-980117 (UNIX) (OSF1/V2.0 (alpha)) Newsgroups: comp.lang.ada Date: 1999-09-08T00:00:00+00:00 List-Id: Joe Wisniewski 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" 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