comp.lang.ada
 help / color / mirror / Atom feed
From: "Norman H. Cohen" <ncohen@watson.ibm.com>
Subject: Re: Building portable data structure (NOT a newbie question?)
Date: 1996/12/27
Date: 1996-12-27T00:00:00+00:00	[thread overview]
Message-ID: <32C4465E.1156@watson.ibm.com> (raw)
In-Reply-To: E336qt.BtG@world.std.com


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




  reply	other threads:[~1996-12-27  0:00 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1996-12-27  0:00 Building portable data structure (NOT a newbie question?) afniii
1996-12-27  0:00 ` Robert A Duff
1996-12-27  0:00   ` Norman H. Cohen [this message]
1996-12-27  0:00 ` Mark Eichin
1996-12-27  0:00 ` Robert I. Eachus
1996-12-27  0:00 ` Larry Kilgallen
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox