Rep Specs

Rep Specs

[Doug Shipler]

I am using SunAda83 version 1.1k on a SunOS Sparc 5.  I have a record
that is rep speced into 32 bit long words.  One of the words is
split up into several fields, one is a 16 bit integer, and the
others are bit flags.  The interesting part is that when I try to
access one of the bit flags, the compiler fetches the wrong bit, it
gets a bit from the 16 bit integer field.  

In this example, Flag3 accesses a bit inside Value.

for My_Record_Typ use
     record at mod 32;
          Value at 0 * 4 range 16 .. 31;
          Flag1 at 0 * 4 range 15 .. 15;
          Flag2 at 0 * 4 range 13 .. 14;
          Unused1 at 0 * 4 range 10 .. 12;
          Flag3 at 0 * 4 range 9 .. 9;
          Flag4 at 0 * 4 range 8 .. 8;
          Unused2 at 0 * 4 range 4 .. 7;
          OtherVal at 0 * 4 range 0 .. 3;
          ........

Any ideas are greatly appreciated!

Re: Rep Specs

[Stephen Leake]

Doug Shipler wrote:
> 
> I am using SunAda83 version 1.1k on a SunOS Sparc 5.  I have a record
> that is rep speced into 32 bit long words.  One of the words is
> split up into several fields, one is a 16 bit integer, and the
> others are bit flags.  The interesting part is that when I try to
> access one of the bit flags, the compiler fetches the wrong bit, it
> gets a bit from the 16 bit integer field.
> 
> In this example, Flag3 accesses a bit inside Value.
> 
> for My_Record_Typ use
>      record at mod 32;
>           Value at 0 * 4 range 16 .. 31;
>           Flag1 at 0 * 4 range 15 .. 15;
>           Flag2 at 0 * 4 range 13 .. 14;
>           Unused1 at 0 * 4 range 10 .. 12;
>           Flag3 at 0 * 4 range 9 .. 9;
>           Flag4 at 0 * 4 range 8 .. 8;
>           Unused2 at 0 * 4 range 4 .. 7;
>           OtherVal at 0 * 4 range 0 .. 3;
>           ........
> 
> Any ideas are greatly appreciated!

I ran into a similar problem. The cause is that the Sparc is
little-bit-endian; it stores the least significant bit in the highest
numbered bit slot.

This is how I solved the problem in a (so far) portable way:

------------ for Intel/gnat ---------------
with System;
package Endianness
  -- Purpose:
  --    define constants to reflect hardware bit and word endianness in
  --    record representation clauses (in Ada83). Obviously, this file
is
  --    highly system-dependent (Ada95 solves this much more nicely!).
is
  -- this is for gnat on an Intel 386 compatible processor
  System_Name : System.NAME := System.SYSTEM_NAME_GNAT;

  Bit_Order : constant := 1;
  High_Bit_First : constant := 1;
  Low_Bit_First : constant := 0;
  MSBit : constant := 7;
  LSBit : constant := 0;

  type Byte_Order_Type is (BIG_ENDIAN, LITTLE_ENDIAN);
  Byte_Order : constant Byte_Order_Type := LITTLE_ENDIAN;

end Endianness;

------------------- for Sparc/SunAda --------------------
with System;

package Endianness

  -- Purpose:

  --    define constants to reflect hardware bit and word endianness in

  --    record representation clauses (in Ada83). Obviously, this file
is

  --    highly system-dependent (Ada95 solves this much more nicely!).

is

  -- this is for Sun (Verdix) Ada on a Sparc processor

  System_Name : System.NAME := System.SUN4_UNIX;



  Bit_Order : constant := -1;

  High_Bit_First : constant := 0;

  Low_Bit_First : constant := 1;

  MSBit : constant := 0;

  LSBit : constant := 7;



  type Byte_Order_Type is (BIG_ENDIAN, LITTLE_ENDIAN);

  Byte_Order : constant Byte_Order_Type := BIG_ENDIAN;



end Endianness;


Then, a rep clause looks like:
  type Out_Health_Flags_Type is record
    User_Ephemeris_Needed       : BOOLEAN;
    Approximate_GPS_Time_Needed : BOOLEAN;
    Self_Survey_Data_Needed     : BOOLEAN;
    Almanac_Not_Current         : BOOLEAN;
    Operational_Status          : OPERATIONAL_STATUS_TYPE;
  end record;
  for Out_Health_Flags_Type use record
    User_Ephemeris_Needed       at 0 
	range LSBit + Bit_Order * 0 .. LSBit + Bit_Order * 0;
    Approximate_GPS_Time_Needed at 0 
	range LSBit + Bit_Order * 1 .. LSBit + Bit_Order * 1;
    Self_Survey_Data_Needed     at 0 
	range LSBit + Bit_Order * 2 .. LSBit + Bit_Order * 2;
    Almanac_Not_Current         at 0 
	range LSBit + Bit_Order * 3 .. LSBit + Bit_Order * 3;
    Operational_Status          at 0 range
      High_Bit_First * (LSBit + Bit_Order * 4) +  
	Low_Bit_First * (LSBit + Bit_Order * 7) ..
      Low_Bit_First  * (LSBit + Bit_Order * 4) + 
	High_Bit_First * (LSBit + Bit_Order * 7);
  end record;
  for Out_Health_Flags_Type'Size use 8;

As long as you include the proper version of Endianness in your library,
the rep clause is correct for either little-bit-endian (Sparc) or
big-bit-endian (Intel).

Note that the issue of byte-endianness doesn't show up in the rep
clause; that's handled by the `at 0', as long as Storage_Unit is 8 bits.
Byte-endianness shows up when converting multi-byte values to byte
arrays:

  function To_2_Byte is new Unchecked_Conversion
    (TARGET => Byte_Array_2_Type,
     SOURCE => Geode_Types.INTEGER);

  procedure To_Network
    (Item : in Geode_Types.INTEGER;
     Buffer : out Geode_Types.BYTE_ARRAY;
     Last : in out Geode_Types.INTEGER)
  is
    use Geode_Types;
  begin
    case Byte_Order is
    when BIG_ENDIAN =>
      Buffer (Last+1  .. Last+2) := To_2_Byte (Item);
    when LITTLE_ENDIAN =>
      declare
        Temp : constant BYTE_ARRAY (1 .. 2) := To_2_Byte (Item);
      begin
        Buffer (Last+1) := Temp (2);
        Buffer (Last+2) := Temp (1);
      end;
    end case;
    Last := Last+2;
  end To_Network;

You MUST test this code for each compiler/hardware combination; some may
do the integer <> byte array unchecked conversion differently.

-- 
- Stephe

Re: Rep Specs,endian,ncohen

[Peter Hermann]

: I ran into a similar problem. The cause is that the Sparc is
: little-bit-endian; it stores the least significant bit in the highest
: numbered bit slot.
: This is how I solved the problem in a (so far) portable way:

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

--
Peter Hermann  Tel:+49-711-685-3611 Fax:3758 ph@csv.ica.uni-stuttgart.de
Pfaffenwaldring 27, 70569 Stuttgart Uni Computeranwendungen
Team Ada: "C'mon people let the world begin" (Paul McCartney)

Re: Rep Specs,endian,ncohen

[Norman H. Cohen]

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: Rep Specs,endian,ncohen

[Stephen Leake]

Norman H. Cohen wrote:
> 
> 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.

Yes, it is, and I apologize for not giving proper credit. I couldn't
remember where I had learned the technique!

-- 
- Stephe

Re: Rep Specs

[Robert Dewar]

Stephen Lake said, responding to Doug Shipler's problem:

  "I ran into a similar problem. The cause is that the Sparc is
  little-bit-endian; it stores the least significant bit in the highest
  numbered bit slot."

  and then follows a very contorted work around!

No, that's not the cause. The quoted code is quite correct, and should
work on either a little endian or big-endian machine. If it does not
you have run into a compiler bug. Your suggestion might be reasonable
as a work around, but we should not leave the impression that this
work around is neccessary on a correctly functioning Ada compiler!

Rep specs

[Eddy Raineri]

Hello,
I have a question regarding rep specs.  There is an individual I work with
that has stated that rep specs are not required by the LRM and as I qoute
"DO NOT USE ADA REP SPECS except in the simplest of cases, or unless you are
sure that the code will NEVER be ported to a different machine or compiler
(hah!)"

I had a totally different opinion.  So I have the following questions.

1)  I was under the impression that it was.  It is in chapter 13 and not an
annex.  Is it required?
2)  I was also thought that using rep specs is ideal for dealing with
porting issues and cross platform communications.  I.E. if a 32 bit PC was
talking to an 8 bit microcontroller via a serial line.  Is this correct?
3)  I also thought that by using rep specs you may not be optimizing the
code correctly for the platform but you are assuring that it will port
correctly to another compiler/platform without any heartburn.
4) I also beleived that using pragm pack and rep spec will allow you to
correctly access hardware registers correctly without using complex bit
manipulation techniques or extra code.


Thanks in advance for you help
E. Raineri

Re: Rep specs

[Robert Dewar]

In article <tqx43.5040$xF2.70329@news1.rdc2.tx.home.com>,
  "Eddy Raineri" <eraineri@axiom-tx.com> wrote:
> Hello,
> I have a question regarding rep specs.  There is an individual
I work with
> that has stated that rep specs are not required by the LRM and
as I qoute
> "DO NOT USE ADA REP SPECS except in the simplest of cases, or
unless you are
> sure that the code will NEVER be ported to a different machine
or compiler
> (hah!)"
>

Rep specs (more properly rep clauses) are not required unless
you implement the Systems Programming Annex. That makes sense.
For the type of thing that needs rep clauses, that annex had
better be implemented. In fact virtually all compilers support
this on virtually all machines. An exception might be a compiler
targetting the JVM, where systems programming is not really
practical in any case.

However, the "individual you work with" is QUITE wrong in
reocmmending against using rep clauses completely. As you
point out in your examples, careful use of rep clauses (as
well as address attributes etc) can greatly AID in portability.
Forbidding these features may very well cause you to have to
resort to low level do-it-your-self stuff which will be much
less likely to be portable.


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: Rep specs

[czgrr]

In article <7iuqvu$lpp$1@nnrp1.deja.com>,
  Robert Dewar <robert_dewar@my-deja.com> wrote:
> In article <tqx43.5040$xF2.70329@news1.rdc2.tx.home.com>,
>   "Eddy Raineri" <eraineri@axiom-tx.com> wrote:
> > Hello,
> > I have a question regarding rep specs.  There is an individual
> I work with
> > that has stated that rep specs are not required by the LRM and
> as I qoute
> > "DO NOT USE ADA REP SPECS except in the simplest of cases, or
> unless you are
> > sure that the code will NEVER be ported to a different machine
> or compiler
> > (hah!)"
> >
>
> However, the "individual you work with" is QUITE wrong in
> reocmmending against using rep clauses completely. As you
> point out in your examples, careful use of rep clauses (as
> well as address attributes etc) can greatly AID in portability.
> Forbidding these features may very well cause you to have to
> resort to low level do-it-your-self stuff which will be much
> less likely to be portable.
>
As an example of this, I ported (in Ada 83, BTW) a real time simulator
from a UNIX VADS compiler to Windows 95-based ActivAda. It communicated
with a GUI written in Visual C++ using formatted LAN messages.

Now, in this case, using 'SIZE to specify the length of scalar types
was very important because there were differences between the two
compilers/machines that would have misaligned the message formats after
the port. Using 'SIZE meant that there was no change.

The messages would also have been messed up had we not used the
occasional USE clause for a record, in the few cases where the C++
record was larger than the Ada record, and hence the Ada record needed
'padding'. Personally, though, I don't like them.

Also, representation clauses were used to specify what values all
enumerals should have because we did have some (not many, I grant you)
which were not 0, 1, 2, etc. Most were not necessary, since both Ada
and C++ defaults to 0, 1, 2, etc, but they were put in anyway "to make
sure" as it is much easier to check against C++ if a problem arose.

So I agree that it is wrong to ban representation clauses completely,
since they most definitely eased the transition process and were
actually necessary in several cases. I also have to say that I do
believe that their use should be limited to where they *are* necessary,
quite apart from the maintenance nightmare when one has over 100
layered records and a low-level record is changed!

Cheers,
czgrr

--
No email, please - reply to the newsgroup. Email may be made public.
My opinions are not necessarily those of my employer.
My suggestions might not be correct. Use at your own risk.


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: Rep specs

[Steve Quinlan]

Read section 13 carefully. There are lots of vendor weasel words in there.
"Recommended  level of support", "an implementation may place
implementation-defined restrictions on representation items", the
"implementation advice" sections. All this means that representation clause
support can vary significantly from one vendor to another.

That doesn't mean "never use it", it means use it with your eyes open, be aware
of the implementation dependent aspects of it. Also it matters WHY you are using
it. There are a number of different things you might want to accomplish here.
Determine which features of ch 13 you need, and determine with current and
potential future compiler vendors what their level of support is for those
features. They are supposed to document any restrictions they impose, advice
they don't follow, etc. If you can't find the information in their
documentation, then ask them.

For example, with record representation clauses, maybe you are trying to achieve
common data representation between different vendors (assuming things like
endian-ness and FP format don't get in the way). Maybe you only want to assure a
common representation from release to release of a single compiler (they are
allowed to change the default lay out of data unless told otherwise by a rep
clause). Maybe you want to match some register format or external data layout.

If you're a big enough customer, the vendor(s) can be persuaded (and paid) to do
things more to your liking (e.g., remove a restriction that they put in just for
their convenience, but which you need removed), follow some implementation
advice which they chose not to, etc.

Re: Rep specs

[Robert Dewar]

In article <37542022.789354FD@nospam.lmco.com>,
  Steve Quinlan <steven.quinlan@nospam.lmco.com> wrote:
> Read section 13 carefully. There are lots of vendor weasel
> words in there.
> "Recommended  level of support", "an implementation may place
> implementation-defined restrictions on representation items",
> the
> "implementation advice" sections. All this means that
> representation clause
> support can vary significantly from one vendor to another.

That's over-pessimistic. All the sections in chapter 13 under
recommended level of support become REQUIREMENTS for a compiler
implementing the systems programming annex. Clearly if you want
to use rep clauses, you should choose a compiler that supports
this annex (virtually all compilers do), and then, if possible
restrict your use of rep clauses to those that are included
in these sections on recommended level of support.




Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: Rep specs

[Marin David Condic]

Robert Dewar wrote:
> Rep specs (more properly rep clauses) are not required unless
> you implement the Systems Programming Annex. That makes sense.
> For the type of thing that needs rep clauses, that annex had
> better be implemented. In fact virtually all compilers support
> this on virtually all machines. An exception might be a compiler
> targetting the JVM, where systems programming is not really
> practical in any case.
> 
O.K. Now you've got me confused. Chapter 13 clearly defines syntax for
representation clauses, but allows for interpretation in an
implementation defined manner. That would seem to "require" support for
representation clauses, even if the level of support is questionable.
I'd imagine the compiler would be required to parse the clause and at
least say something to the effect of "I know you asked for this, but I
can't give it to you, so you get this other thing instead..." At least
you are warned that the representation is not possible with the given
implementation. (I'd agree that a compiler which refused to comply with
all rep clauses no matter how trivial, would be behaving rather silly,
but isn't that still some form of support?)

I'd agree that the issue is rather one of hair splitting and mostly
irrelavent since representation clauses are generally fully supported.
But wouldn't the issue arise again for things such as pragmas? "Yes I
recognize your pragma, but no, I'm not going to do anything about it" is
a valid form of support. Or am I wrong on this score?

MDC
-- 
Marin David Condic
Real Time & Embedded Systems, Propulsion Systems Analysis
United Technologies, Pratt & Whitney, Large Military Engines
M/S 731-95, P.O.B. 109600, West Palm Beach, FL, 33410-9600
***To reply, remove "bogon" from the domain name.***

Visit my web page at: http://www.flipag.net/mcondic

Re: Rep specs

[Samuel T. Harris]

Eddy Raineri wrote:
> 
> Hello,
> I have a question regarding rep specs.  There is an individual I work with
> that has stated that rep specs are not required by the LRM and as I qoute
> "DO NOT USE ADA REP SPECS except in the simplest of cases, or unless you are
> sure that the code will NEVER be ported to a different machine or compiler
> (hah!)"
> 
> I had a totally different opinion.  So I have the following questions.
> 
> 1)  I was under the impression that it was.  It is in chapter 13 and not an
> annex.  Is it required?
> 2)  I was also thought that using rep specs is ideal for dealing with
> porting issues and cross platform communications.  I.E. if a 32 bit PC was
> talking to an 8 bit microcontroller via a serial line.  Is this correct?
> 3)  I also thought that by using rep specs you may not be optimizing the
> code correctly for the platform but you are assuring that it will port
> correctly to another compiler/platform without any heartburn.
> 4) I also beleived that using pragm pack and rep spec will allow you to
> correctly access hardware registers correctly without using complex bit
> manipulation techniques or extra code.
> 
> Thanks in advance for you help
> E. Raineri

In my experiences interfacing to hardware, as well as other
languages, representation clauses are vital and mandatory
in these situations. Therefore, their support becomes
requirements for the target compiler/platform.

If you have to force the layout of a record to conform
to the storage layout of a memory mapped hardware device,
then you must have the appropriate representation clause.
Any compiler which does not support it is simply not a
viable candidate target compiler.

When supporting a new platform, compiler selection must
satisfy your requirements and if you need representation
clauses then they are in your requirements.

Except for the earliest Ada 83 compilers, I have not run
into significant issues with missing Chapter 13 features
from 1985 to the present. That does not preclude the
necessity of identifying these needs as requirements and
verifying candidate compilers satisfy these needs.
So I have rarely eliminated a candidate compiler from
consideration due to limitation in their Chapter 13 support.

Along this line, I've found that the new pragma convention
in Ada 95 has made nearly all my code supporting interfacing
with other languages obsolete. It is very convenient.
And the systems programming annex does a very nice job of
encapsulating the requirements of this problem domain.
When considering Ada 83 compilers, I used to have a laundry
list of Chapter 13 features which are required. With Ada 95,
I simply need say "fully implements the systems programming
annex" and I sleep well knowing my bases are covered.

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

Re: Rep specs

[Robert Dewar]

In article <3756CA64.A9EF5BA3@hso.link.com>,
  "Samuel T. Harris" <sam_harris@hso.link.com> wrote:
> With Ada 95,
> I simply need say "fully implements the systems programming
> annex" and I sleep well knowing my bases are covered.
>
> --
> Samuel T. Harris, Principal Engineer
> Raytheon, Scientific and Technical Systems
> "If you can make it, We can fake it!"


Hmmm! In practice we find that very few large customers can live
with the small subset of rep clauses required to be implemented
by the systems programming annex, and a lot of our development
work has been to add capabilities in this area, in response to
customer requirements. Some examples:

 1. Tight packing for other than 1,2,4,8 bits

 2. Size clauses on records and arrays

 3. Integer fields across storage boundaries

 4. Arrays indexed by enumeration types with holes are compact

 5. Record fields on other than natural alignment boundary

There are many others. None of these are required by the SPA.
Sam, are you really sure you stick strictly to the SPA subset?
If so, you are, in our experience an unusual user. As I say,
most of our users, especially those with legacy Ada 83 code,
require far more.

Indeed I would argue that the Ada 83 RM *required* a lot more,
since it required the compiler to accept much more. In Ada 83,
the only allowed restriction was:

  An implementation may limit its acceptance of representation
  clauses to those that can be handled simply by the underlying
  hardware.

Now of course this is vague, since simply is not defined. On
the other hand, it is clear that all the Ada 95 SPA requirements
are indeed in this category. It is also clear that many things
meet this requirement which are NOT required by the Ada 95 SPA.
So in that sense, the requirements, while being more precise,
are actually weaker.

And if you think that is just a theoretical issue, consider that
all major Ada 83 compilers went far beyond the current Ada 95
requirements in practice.






Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.