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,efe03f20164a417b
X-Google-Attributes: gid103376,public
From: ncohen@watson.ibm.com (Norman H. Cohen)
Subject: Re: An observation of Ada (may offend)
Date: 1995/03/27
Message-ID: <3l6sts$12kj@watnews1.watson.ibm.com>#1/1
X-Deja-AN: 100540726
distribution: world
references: <3l640c$308@miranda.gmrc.gecm.com>
organization: IBM T.J. Watson Research Center
reply-to: ncohen@watson.ibm.com
newsgroups: comp.lang.ada
Date: 1995-03-27T00:00:00+00:00
List-Id: <comp.lang.ada>

In article <3l640c$308@miranda.gmrc.gecm.com>, bill@valiant.gmrc.gecm.com
(R.A.L Williams) writes: 

|> I agree that the representation clauses defined in the LRM are splendid,
|> the problem is that they are *optional*. I don't know what the situation
|> is now, but when I last did a lot of work in Ada many compilers had only
|> a fragmentary coverage.

That is no longer the case.  In response to market forces, Ada compilers
have provided genuine support for record-representation clauses for many
years now.

In Ada 95, a compiler cannot claim conformance to the Systems Programming
Annex (and thus not to the Real-Time Systems annex) unless it supports
record-representation clauses.

|> Most of the time, as you say, bit fields are adequate, but how would you
|> implement ECC alogorithms or maximal length sequence generators for instance?
|> So far as standards are concerned, I believe that bit fields are codified
|> in the ANSI C standard, and every ANSI C compiler I've used actually does
|> implement them.

Yes, ANSI compilers must recognize bit-field declarations, but the ANSI C
standard imposes very few constraints on what the compiler is to do with
them.  In contrast, the Ada-83 rules (at least as interpreted by early
implementors) provided some leeway to reject a record-representation
clause, but an accepted record-representation clause provides an
unambiguous bit-by-bit specification of the intended layout.

It is easy to write Ada-83 record-representation clauses that produce
exactly the same layout for all compilers for, say, 32-bit big-endian
machines.  The Ada-95 pragma Bit_Order even makes it possible to write
clauses that are guaranteed to produce the same bit layout of a record on
all 32-bit machines (big-endian or little-endian).  (Of course you have
to decide what you mean by "the same" on big-endian and little-endian
machines, but whatever you decide, a record-representation clause can be
written to achieve it.)

ANSI C simply says that bit fields are packed as tightly as possible, in
order of declaration, into successive "units" with increasing addresses.
The ANSI C standard explicitly leaves all of the following unspecified: 

   - the size of the unit
   - the direction in which members packed into a single unit are laid
     out in that unit
   - whether a member that does not fit entirely in the current unit
     spans units or begins a new unit.  (A bit field of length zero
     forces a new unit to start, but there is no way to enforce spanning
     of units.)

--
Norman H. Cohen    ncohen@watson.ibm.com