Re: An observation of Ada (may offend)

[ncohen@watson.ibm.com (Norman H. Cohen)]

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