Re: Representation Clause Bit Ordering

["Samuel T. Harris" <sam_harris@hso.link.com>]

Tucker Taft wrote:
> 
> Jeff Susanj wrote:
> >
> > We are trying to define records for an external device that is defined in
> > fractional binary with 16 bit storage units (the leftmost bit is bit 0 and
> > the rightmost bit is 15) and our processor is an integer binary machine with
> > 32 bit storage units (the leftmost bit is bit 32 and the rightmost bit is
> > 0).  I believe there must be some way in Ada to define this and still be
> > portable.
> 
> The Bit_Order attribute is not designed for "flipping"
> bits or bytes.  It simply changes the numbering of bits
> in a record rep clause.
> 
> > ... We have tried using the 'Bit_Order attribute but with the
> > High_Order_First our Green Hills compiler generates 32 bit data which seems
> > consistant with the LRM but doesn't work for our application.  Does anyone
> > have any ideas?
> 
> If you need to flip bits or bytes, you will need to do that yourself
> manually.  You can minimize mistakes by making the flipped-bit type
> private, with operations for fetching/storing "normal" values into it.
> 
> > Jeff Susanj
> 
> --
> -Tucker Taft   stt@averstar.com   http://www.averstar.com/~stt/
> Technical Director, Distributed IT Solutions  (www.averstar.com/tools)
> AverStar (formerly Intermetrics, Inc.)   Burlington, MA  USA

Two anecdotes along these lines.

A group has a hardware device to which they need to interface.
This pretty straigh-forward stuff since the device is
memory mapped to a fixed location. A record-rep clause
and an address clause (Ada 83) works nicely.
Then comes along a software emulation of the device
produced by a third-party contractor. The problem is
the memory map used by the emulator is different from
the actual device. How they got by with that I haven't
a clue. In come some folks to my desk wringing hands
and bemoaning the situation and wondering how they
can pass emulator stuff to the hardware and vice versa
without a lot of memory mangling. I point out that derived
types can have individual rep-clauses. I suggest they
define a parent type with no rep-clause and two derived
types, one for the hardware and one for the software.
Each of the derived type then has the appropriate rep-clause.
A simple type conversion on assignment between the two
kinds of objects and the Ada compiler will handle all
the memory mangling automagically. Problem solved.

I only mention the above because some months later the
same group come to me with another problem. This time
the same memory-mapped device is visible to two different
architectures. Each architecture they are writing code for
uses different compilers. Each compiler uses a different
bit-ordering on the rep-clauses. Lets call them compiler
X and compiler Y. They took all that into account and used
my derived type approach. Then they wondered by the type
conversion failed to produce the desired results. Of course,
by simply pointing out that the rep-clause for compiler Y
was not appropriate for Compiler X, and vice versa, and
that no type conversion is necessary since this situation
did not involve different memory maps, they quickly
saw the error of their ways. I then suggested that this
is more a variant code issue and that having both
representations around would involved process safeguards
to insure the wrong types were not used. Simpler to have
one type (since their is one device and one memory layout)
and leave it to the configuration management system to
insure the correct variant of the code is available.

I suppose the new Ada 95 Bit_Order attribute will
help in this situation if/when we migrate from Ada 83.

-- 
Samuel T. Harris, Principal Engineer
Raytheon, Scientific and Technical Systems
"If you can make it, We can fake it!"