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=0.2 required=5.0 tests=BAYES_00,INVALID_MSGID, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,35d56f705b196731 X-Google-Attributes: gid103376,public From: "Norman H. Cohen" Subject: Re: Building portable data structure (NOT a newbie question?) Date: 1996/12/27 Message-ID: <32C4465E.1156@watson.ibm.com>#1/1 X-Deja-AN: 206276345 references: content-type: text/plain; charset=us-ascii organization: IBM Thomas J. Watson Research Center mime-version: 1.0 reply-to: ncohen@watson.ibm.com newsgroups: comp.lang.ada x-mailer: Mozilla 3.0 (Win95; I) Date: 1996-12-27T00:00:00+00:00 List-Id: Robert A Duff wrote: > Bit_Order specifications are not required on most machines, by the way. > Only on word-addressable machines. This is because on byte-addressable > machines, they can cause gaps within components, which is a pain for the > compiler. The existence of these nasty gaps depends on the interpretation of bit offsets in a nondefault-endian component clause, something that is not specified by the RM. 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 unit 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, it is practical to require all compilers to support nondefault-endian record-representation clauses. Such a requirement would allow a programmer to portably specify a layout in an arbitrary bit order. A compiler that is big-endian by default and a compiler that is little-endian by default would interpret the record-representation clause the same way, i.e., on both a big-endian machine and a little-endian machine, the layout would be divided into "loadable storage units" with the same sizes and byte offsets, and the left-to-right bit position of each record component within corresponding loadable storage units would be the same. -- Norman H. Cohen mailto:ncohen@watson.ibm.com http://www.research.ibm.com/people/n/ncohen