Re: Representation Clause Bit Ordering

Re: Representation Clause Bit Ordering

[Tucker Taft]

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

Re: Representation Clause Bit Ordering

[Samuel T. Harris]

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!"

Re: Representation Clause Bit Ordering

[Joe Wisniewski]

OK, those of good long-term memories.... was it in Ada Letters about
4-5 years ago, there was a paper written about something very close
to this issue; or an endian-ness independent approach for rep-specs,
or something like this???????

Joe

Tucker Taft wrote in message <37860BA1.CF7E58B2@averstar.com>...
>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

Re: Representation Clause Bit Ordering

[Peter Hermann]

Joe Wisniewski <wisniew@acm.org> wrote:
> OK, those of good long-term memories.... was it in Ada Letters about
> 4-5 years ago, there was a paper written about something very close
> to this issue; or an endian-ness independent approach for rep-specs,
> or something like this???????

I dug out the following:

--snip--snip--snip--snip--snip--snip--snip--snip--snip--snip--snip

From: "Norman H. Cohen" <ncohen@watson.ibm.com>
Newsgroups: comp.lang.ada
Subject: Re: Rep Specs,endian,ncohen
Date: Thu, 10 Oct 1996 12:02:05 -0400
Organization: IBM Thomas J. Watson Research Center
Lines: 83
Message-ID: <325D1DFD.3DE1@watson.ibm.com>
References: <3259589E.1740@smtp.svl.trw.com> <325A510D.14E1@gsfc.nasa.gov> <53g3ag$1otk@info4.rus.uni-stuttgart.de>
Reply-To: ncohen@watson.ibm.com
NNTP-Posting-Host: socks1.watson.ibm.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: Mozilla 3.0 (Win95; I)

Peter Hermann wrote:

> I remember Norman H. Cohen has written an essay about the endian
> /portability problem somewhere in AdaLetters(?).

"Endian-Independent Record Representation Clauses", Ada Letters XIV, No.
1 (January/February 1994), pp. 27-29

Stephen Leake's solution appears to be an instance of the approach
suggested in the article.  The article gives the general recipe for
constructing the component clauses.

Note that the problem being solved here is the porting of the source
text for record-representation clauses, NOT the run-time translation of
a byte stream from one endianness to another.

Please disregard the assertion in the article that this problem would be
solved in Ada 9X by an attribute definition clause for the 'Bit_Order
attribute.  The implementation advice in RM95-13.5.3(8) allows a
compiler to reject an attribute-definition clause for the nondefault bit
order in all the useful cases.  

Compilers are generally allowed to reject nondefault 'Bit_Order
definitions because the designers of Ada 95 believed that component
clauses interpreted according to the nondefault bit order could specify
noncontiguous bit fields, an implementation nightmare.  However, that
depends on how you interpret the meaning of a bit offset in a
nondefault-endian component clause.  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 field 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, there is a one-to-one
correspondence between record representation clauses that specify a
given layout when interpreted as big-endian clauses and other record
representation clauses that specify the "same" layout when interpreted
as little-endian representation clauses.  (I explain below what I mean
when I say that layouts are the "same".)  Thus it would be practical to
require all compilers to support nondefault-endian record-representation
clauses, with an attribute-definition clause for T'Bit_Order determining
how the record-representation clause for type T is to be interpreted. 
This would solve the source portability problem by allowing the
programmer to arbitrarily specify a layout in his favorite bit order,
knowing that a compiler that is big-endian by default and a compiler
that is little-endian by default will interpret the
record-representation clause the "same" way.  

When I say that a layout on a big-endian machine and a layout on a
little-endian machine are the "same", I mean that the layout is divided
into "loadable storage units" with the same sizes and byte offsets, and
that the left-to-right bit position of each record component within
corresponding loadable storage units is the same.  These are the only
properties of a layout that can be usefully preserved among
opposite-endian machines.

-- 
Norman H. Cohen
mailto:ncohen@watson.ibm.com
http://www.research.ibm.com/people/n/ncohen

Re: Representation Clause Bit Ordering

[Pat Rogers]

I have simple package supporting this approach for Ada 95 at

http://www.classwide.com/products/freecode.htm


Peter Hermann <ica2ph@alpha1.csv.ica.uni-stuttgart.de> wrote in message
news:7r5861$gob$1@infosun2.rus.uni-stuttgart.de...
> Joe Wisniewski <wisniew@acm.org> wrote:
> > OK, those of good long-term memories.... was it in Ada Letters about
> > 4-5 years ago, there was a paper written about something very close
> > to this issue; or an endian-ness independent approach for rep-specs,
> > or something like this???????
>
> I dug out the following:
>
> --snip--snip--snip--snip--snip--snip--snip--snip--snip--snip--snip
>
> From: "Norman H. Cohen" <ncohen@watson.ibm.com>
> Newsgroups: comp.lang.ada
> Subject: Re: Rep Specs,endian,ncohen
> Date: Thu, 10 Oct 1996 12:02:05 -0400
> Organization: IBM Thomas J. Watson Research Center
> Lines: 83
> Message-ID: <325D1DFD.3DE1@watson.ibm.com>
> References: <3259589E.1740@smtp.svl.trw.com>
<325A510D.14E1@gsfc.nasa.gov> <53g3ag$1otk@info4.rus.uni-stuttgart.de>
> Reply-To: ncohen@watson.ibm.com
> NNTP-Posting-Host: socks1.watson.ibm.com
> Mime-Version: 1.0
> Content-Type: text/plain; charset=us-ascii
> Content-Transfer-Encoding: 7bit
> X-Mailer: Mozilla 3.0 (Win95; I)
>
> Peter Hermann wrote:
>
> > I remember Norman H. Cohen has written an essay about the endian
> > /portability problem somewhere in AdaLetters(?).
>
> "Endian-Independent Record Representation Clauses", Ada Letters XIV,
No.
> 1 (January/February 1994), pp. 27-29
>
> Stephen Leake's solution appears to be an instance of the approach
> suggested in the article.  The article gives the general recipe for
> constructing the component clauses.
>
> Note that the problem being solved here is the porting of the source
> text for record-representation clauses, NOT the run-time translation
of
> a byte stream from one endianness to another.
>
> Please disregard the assertion in the article that this problem would
be
> solved in Ada 9X by an attribute definition clause for the 'Bit_Order
> attribute.  The implementation advice in RM95-13.5.3(8) allows a
> compiler to reject an attribute-definition clause for the nondefault
bit
> order in all the useful cases.
>
> Compilers are generally allowed to reject nondefault 'Bit_Order
> definitions because the designers of Ada 95 believed that component
> clauses interpreted according to the nondefault bit order could
specify
> noncontiguous bit fields, an implementation nightmare.  However, that
> depends on how you interpret the meaning of a bit offset in a
> nondefault-endian component clause.  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 field 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, there is a one-to-one
> correspondence between record representation clauses that specify a
> given layout when interpreted as big-endian clauses and other record
> representation clauses that specify the "same" layout when interpreted
> as little-endian representation clauses.  (I explain below what I mean
> when I say that layouts are the "same".)  Thus it would be practical
to
> require all compilers to support nondefault-endian
record-representation
> clauses, with an attribute-definition clause for T'Bit_Order
determining
> how the record-representation clause for type T is to be interpreted.
> This would solve the source portability problem by allowing the
> programmer to arbitrarily specify a layout in his favorite bit order,
> knowing that a compiler that is big-endian by default and a compiler
> that is little-endian by default will interpret the
> record-representation clause the "same" way.
>
> When I say that a layout on a big-endian machine and a layout on a
> little-endian machine are the "same", I mean that the layout is
divided
> into "loadable storage units" with the same sizes and byte offsets,
and
> that the left-to-right bit position of each record component within
> corresponding loadable storage units is the same.  These are the only
> properties of a layout that can be usefully preserved among
> opposite-endian machines.
>
> --
> Norman H. Cohen
> mailto:ncohen@watson.ibm.com
> http://www.research.ibm.com/people/n/ncohen
>