Ada Portability... NOT!

Ada Portability... NOT!

[Capt. Britt Snodgrass]

One recent post contained what I considered an overstatement of the
portability of Ada programs.  Let me describe my current problem and
hopefully many of you will provide some insight into the root cause.

I'm currently trying to port some avionics test data processing
software from an HP 9000/380 (HP-UX 8.00) to an HP-9000/735 (HP-UX
9.03).  The model 380 has a Motorola 68040 CPU while the model 735 has
a Hewlett-Packard PA-RISC CPU.  The code was orignially developed on the
model 380 using the VADS 6.0 Ada compiler.  The Ada compiler on the
model 735 is VADS 6.2.1(k).

All code compiled and executed correctly on the model 380.  I assumed
it would be a simple matter to copy all the source code to the model
735 and recompile it since I was still using the same vendors
compiler.  However, the following error messages came from the code
segment I've included at the end of this message.


ERROR MESSAGES:
*********************************  gps_io_.a  ***********************

 103:      Channel2 at   70 range 0..367;
A ---------^
A:error: Appendix F: component must be aligned on a 8 byte boundary
 104:      Channel3 at  116 range 0..367;
A ---------^
A:error: Appendix F: component must be aligned on a 8 byte boundary
 105:      Channel4 at  162 range 0..367;
A ---------^
A:error: Appendix F: component must be aligned on a 8 byte boundary
m
********************************************************************

QUESTION 1: What have I done wrong, if anything?  I'm familiar with
the Ada Style Guide and its cautions on the use of representation
clauses.  We feel these representation clauses are necessary to make
our data records match the packed binary data we read from disk files.

QUESTION 2: Do RISC processors actually require such strict (8 byte
boundary) alignment constraints?  VADS 6.2 for Windows NT on an Intel
i486 processor (non-RISC) enforces the same constraint but maybe
because Windows NT is also available for RISC processors.  Do the
creators of GNAT have any insight on this?  (Rational tech support
couldn't answer it).



CODE:
-------------------------------------------------------------------
   type ICD_IRG_010_Channel_Type is record
      ChID              : Short_Int;  -- 2 bytes
      PRN               : Short_Int;  -- 2 bytes
      Frequency         : Short_Int;  -- 2 bytes
      Code              : Short_Int;  -- 2 bytes
      TrackingState     : Short_Int;  -- 2 bytes
      CarToNo           : Short_Int;  -- 2 bytes
      RCVRMeasValid     : Short_Int;  -- 2 bytes
      PseudoRangeMeas   : Real;       -- 8 bytes
      DeltaRangeMeas    : Real;       -- 8 bytes
      dtDeltaRange      : Real;       -- 8 bytes
      Spare             : Real;       -- 8 bytes
   end record;

   for ICD_IRG_010_Channel_Type use record at mod 8;
      ChID            at  0 range 0..15;
      PRN             at  2 range 0..15;
      Frequency       at  4 range 0..15;
      Code            at  6 range 0..15;
      TrackingState   at  8 range 0..15;
      CarToNo         at 10 range 0..15;
      RCVRMeasValid   at 12 range 0..15;
      PseudoRangeMeas at 14 range 0..63;
      DeltaRangeMeas  at 22 range 0..63;
      dtDeltaRange    at 30 range 0..63;
      Spare           at 38 range 0..63;
   end record;

   for ICD_IRG_010_Channel_Type'size use 8 * 46;  -- 46 bytes

   type ICD_IRG_010_Corrected_Input_Type is record
      tBlock   : Real;
      tMeasU20 : Real;
      tOffsetU : Real;
      Channel1 : ICD_IRG_010_Channel_Type;
      Channel2 : ICD_IRG_010_Channel_Type;
      Channel3 : ICD_IRG_010_Channel_Type;
      Channel4 : ICD_IRG_010_Channel_Type;
      Channel5 : ICD_IRG_010_Channel_Type;
   end record;

   for ICD_IRG_010_Corrected_Input_Type use
      record at mod 8;
      tBlock   at    0 range 0..63;
      tMeasU20 at    8 range 0..63;
      tOffsetU at   16 range 0..63;
      Channel1 at   24 range 0..367;
      Channel2 at   70 range 0..367;                    -- line 103
      Channel3 at  116 range 0..367;                    -- line 104
      Channel4 at  162 range 0..367;                    -- line 105
      Channel5 at  208 range 0..367;
   end record;

   for ICD_IRG_010_Corrected_Input_Type'size use 254 * 8;

   type ICD_IRG_010_Channel_Array_Type is
      array(Short_Int range 1..5) of ICD_IRG_010_Channel_Type;


================================================================
Capt Britt Snodgrass           e-mail: britt@molokai.46tg.af.mil
                               member: Team Ada & Team OS/2
================================================================

Re: Ada Portability... NOT!

[Robert Dewar]

It is probably a reasonable implementation choice to restrict reals to be
on a properly aligned boundary, since it is an annoying amount of fiddling
to deal with unaligned floating-point stuff, and yes, of course most 
processors *do* require floating-point values to be aligned. When you use
rep clauses you are definitely wandering into the area of implementation
dependent non-portable constructs (most appropriately, since one of the
functions of rep clauses is to deal with special target dependent
requirements).

There is certainly no *requirement* that an implementation reject these
declarations on a RISC machine, the code generator could generate the
code to fiddle around and copy the value. Is it a good idea to do this
behind the scenes? Not clear. Suppose a user just casually wrote rep
clauses to pack the data in a way that worked fine on one machine but
generated long inefficient sequences of code on another, do you want
to be allowed or stopped? Either answer is possible.

I certainly would never have written the original code, and I certainly
would never have written it expecting it to be portable. Writing portable
code in Ada does not come for free, it requires some consideration of 
what is and what is not implementation dependent, and this is especially
true of writing portable code containing rep clauses.

A more portable approach in your particular case is to read the data into
a byte stream (in Ada 9X, use a Storage_Array), and then use unchecked
conversion to convert the data to usable floating-point form. 

Isn't that interesting? The above advice says that you can make the code
*more* portable by using unchecked_conversion. Often people have a knee-jerk
reaction to avoid UC in portable code, but that's quite misinformed. Just as
a careful C programmer will use (carefully chosen) cross-type casts to
achieve portability, a careful Ada programmer can use (carefully chosen)
unchecked conversions.

Actually in Ada 9X, this sort of problem is much better handled using
streams in any case.

Re: Ada Portability... NOT!

[Carlos Perez]

Capt. Britt Snodgrass (britt@molokai.46tg.af.mil) wrote:
: One recent post contained what I considered an overstatement of the
: portability of Ada programs.  Let me describe my current problem and
: hopefully many of you will provide some insight into the root cause.

You can definitely create non-portable in Ada very quickly!  Can
we say UNCHECKED_CONVERSION, boys and girls?  ;-)

: I'm currently trying to port some avionics test data processing
: software from an HP 9000/380 (HP-UX 8.00) to an HP-9000/735 (HP-UX
: 9.03).  The model 380 has a Motorola 68040 CPU while the model 735 has
: a Hewlett-Packard PA-RISC CPU.  The code was orignially developed on the
: model 380 using the VADS 6.0 Ada compiler.  The Ada compiler on the
: model 735 is VADS 6.2.1(k).

Always check the endianess of your new machine.  I think the 68000 is
big endian, don't know about the HP RISC, but I would guess you're o.k.
This can be particularly important if you're reading a bunch o' bits.

: All code compiled and executed correctly on the model 380.  I assumed
: it would be a simple matter to copy all the source code to the model
: 735 and recompile it since I was still using the same vendors
: compiler.  However, the following error messages came from the code
: segment I've included at the end of this message.

I'm no compiler expert, but I don't think it should have compiled before.
Your code says "align ICD_IRG_010_Channel_Type at an 8 byte boundary" using
_at mod 8_ alignment clause and then proceeds to declare another record
called ICD_IRG_010_Corrected_Input_Type that essentially violates
your alignment.  Maybe this should be _at mod 2_?

Create an assembly language listing of your old code and see if VADS 6.0
was ignoring/overriding your alignment clause.  Look at your data
structures, etc. and see if _Channels are on 8-byte multiples or not. 
Look for compiler inserted "spares bytes", too.

: ERROR MESSAGES:

Error messages seem reasonable, if I understand your situation.

: QUESTION 1: What have I done wrong, if anything?  I'm familiar with
: the Ada Style Guide and its cautions on the use of representation
: clauses.  We feel these representation clauses are necessary to make
: our data records match the packed binary data we read from disk files.

Nothing wrong with your code except for explicit 8-byte alignment,
if you require that your Reals be processed on 8-byte multiples,
congratulations!  You need code to shift/manipulate/unpack and re-align
your Reals.  What a headache and I hope that the machines can process
Reals on even boundaries.  If your old code "worked" before, then you
don't need 8-byte alignment, again, check your machines language docs.

: QUESTION 2: Do RISC processors actually require such strict (8 byte
: boundary) alignment constraints?  VADS 6.2 for Windows NT on an Intel
: i486 processor (non-RISC) enforces the same constraint but maybe
: because Windows NT is also available for RISC processors.  Do the
: creators of GNAT have any insight on this?  (Rational tech support
: couldn't answer it).

In the case of floating-point, maybe, I don't know anything about these
machines, sorry...  but I think the real problem lies with the declarations,
not the type of machine.

: CODE:

[snip, see previous post]

: ================================================================
: Capt Britt Snodgrass           e-mail: britt@molokai.46tg.af.mil
:                                member: Team Ada & Team OS/2
: ================================================================

Good luck, hope this helps...

-- Carlos

Re: Ada Portability... NOT!

[Carlos Perez]

Robert Dewar (dewar@cs.nyu.edu) wrote:
: A more portable approach in your particular case is to read the data into
: a byte stream (in Ada 9X, use a Storage_Array), and then use unchecked
: conversion to convert the data to usable floating-point form. 

: Isn't that interesting? The above advice says that you can make the code
: *more* portable by using unchecked_conversion. Often people have a knee-jerk
: reaction to avoid UC in portable code, but that's quite misinformed. Just as
: a careful C programmer will use (carefully chosen) cross-type casts to
: achieve portability, a careful Ada programmer can use (carefully chosen)
: unchecked conversions.

Count me in as one of those knee-jerk liberal Ada programmers ;-).  I guess
I've seen so many bad UC cases that its hard to imagine that it can be used
to create portable code.  For example, how do you "portably" take
care of the "endianess" of a machine that has plagued programmers since
the Dawn of Computing?  I certainly wouldn't write a generic byte-swapping
package unless I was force too.  And what about octal-hex converstions?
There may be a few old octal machines floating around (PDP's?) in 
garage sales somewhere (or in old military aircraft, I suppose).

: Actually in Ada 9X, this sort of problem is much better handled using
: streams in any case.

Cool... I'm new to 9X and will check this feature out.  Thanks for 
help!  I knew there was a reason I was a closet "team Ada" advocate!

-- Carlos

Re: Ada Portability... NOT!

[Niklas Holsti]

In <199411182104.PAA04854@mail.cs.utexas.edu>
britt@molokai.46tg.af.mil (Capt. Britt Snodgrass) writes:

>One recent post contained what I considered an overstatement of the
>portability of Ada programs.  Let me describe my current problem and
>hopefully many of you will provide some insight into the root cause.

I have reordered the following snippets of the error report.
It seems there are two record types called ICD_IRG_010_Channel_Type
and ICD_IRG_Corrected_Input_Type. The latter has several components
of the former type:

>      Channel1 : ICD_IRG_010_Channel_Type;
>      Channel2 : ICD_IRG_010_Channel_Type;
       ...

There is a record representation clause specifying the byte locations
of the components:

>   for ICD_IRG_010_Corrected_Input_Type use
>      record at mod 8;
>      tBlock   at    0 range 0..63;
>      tMeasU20 at    8 range 0..63;
>      tOffsetU at   16 range 0..63;
>      Channel1 at   24 range 0..367;
>      Channel2 at   70 range 0..367;                    -- line 103
       ...

The compiler complains that Channel2 (and some later components)
must be 8-byte aligned:

>ERROR MESSAGES:
>*********************************  gps_io_.a  ***********************

> 103:      Channel2 at   70 range 0..367;
>A ---------^
>A:error: Appendix F: component must be aligned on a 8 byte boundary

I would guess, without being able to test my guess, that the problem
is the alignment specified for the smaller record type:

>   for ICD_IRG_010_Channel_Type use record at mod 8;

This is in contradiction with the byte position (70) specified for
Channel2 within the (8-byte aligned) larger record.  Apparently the
compiler on the former system lets a record rep spec override an
alignment specified for the component types, but the present compiler
does not let you do that. 

Try removing the "at mod 8" for ICD_IRG_010_Channel_Type.  It is not
needed for the code shown in the message, but may, of course, be needed
elsewhere in the program.  If so, I guess you could derive a "new" type
from it, and put a "mod 8" on that. 

>================================================================
>Capt Britt Snodgrass           e-mail: britt@molokai.46tg.af.mil
>                               member: Team Ada & Team OS/2
>================================================================

Hope this helps,
- Niklas Holsti


--
Niklas Holsti                         
  Until 31 Oct 1994 at Department of Computer Science, phone +358 0 708 4423
    P.O. Box 26 (Teollisuuskatu 23), FIN-00014 University of Helsinki, Finland
  From 1 Nov 1994 at Space Systems Finland Ltd, phone +358 0 4354 3928

Re: Ada Portability... NOT!

[Robert Dewar]

Carlos, you wouldn't believe how many "bad" assignment "cases" I have seen
in Ada code written by various people, but that does not make me decided
that assignments are a bad thing.

Properly handled, unchecked conversion is a powerful and important part of
the Ada language, and is often a critical tool in writing portable code. By
portable code, I mean code that can be ported across architectures. 

Typically this involves writing code that is from a formal point of view
entirely implementation dependent, but which, based on rather detailed
knowledge of multiple architectures, which of course few programmers
posess, does in fact work.

It is for example quite possible to defend against endianness differences
using such approaches, but it is by no means easy. 

Re: Ada Portability... NOT!

[Mitch Gart]

One point was implied by Robert's response but wasn't stated
explicitly.  On the HP RISC architecture, if a program 
directly references a mis-aligned piece of data (a 4 byte
quantity aligned on < 4 bytes, or an 8 byte quantity aligned
on < 8 bytes) the machine will trap.  This means that at execution 
time either 

- the program will crash 
- the program will get CONSTRAINT_ERROR
- the compiler will have to generate lots of extra instructions
  to "fiddle" as Robert says, that is, to fetch a quantity a
  few bytes at a time, and put it together into the right 
  data format, then execute some more extra instructions later
  when storing the data back into memory.

The fact that the compiler did none of the above, and instead
rejected the rep clause, seems like a reasonable thing to have
done on the HP machine.
	
	Mitch Gart

Re: Ada Portability... NOT!

[Michael J. Meier]

Capt. Britt Snodgrass (britt@molokai.46tg.af.mil) wrote:
: One recent post contained what I considered an overstatement of the
: portability of Ada programs.  Let me describe my current problem and
: hopefully many of you will provide some insight into the root cause.

: I'm currently trying to port some avionics test data processing
: software from an HP 9000/380 (HP-UX 8.00) to an HP-9000/735 (HP-UX
: 9.03).  The model 380 has a Motorola 68040 CPU while the model 735 has
: a Hewlett-Packard PA-RISC CPU.  The code was orignially developed on the
: model 380 using the VADS 6.0 Ada compiler.  The Ada compiler on the
: model 735 is VADS 6.2.1(k).

We did the same port, but with Alsys compilers, in March for AFATDS.

: All code compiled and executed correctly on the model 380.  I assumed
: it would be a simple matter to copy all the source code to the model
: 735 and recompile it since I was still using the same vendors
: compiler.  However, the following error messages came from the code
: segment I've included at the end of this message.

: ERROR MESSAGES:
: *********************************  gps_io_.a  ***********************

:  103:      Channel2 at   70 range 0..367;
: A ---------^
: A:error: Appendix F: component must be aligned on a 8 byte boundary
: <others omitted for brevity>

: QUESTION 1: What have I done wrong, if anything?  I'm familiar with
: the Ada Style Guide and its cautions on the use of representation
: clauses.  We feel these representation clauses are necessary to make
: our data records match the packed binary data we read from disk files.

The only thing wrong is an expectation that it would be portable.  It would
be even more complicated if you changed to a machine with a different endian
(e.g., VAX or 486).

: QUESTION 2: Do RISC processors actually require such strict (8 byte
: boundary) alignment constraints?  VADS 6.2 for Windows NT on an Intel
: i486 processor (non-RISC) enforces the same constraint but maybe
: because Windows NT is also available for RISC processors.  Do the
: creators of GNAT have any insight on this?  (Rational tech support
: couldn't answer it).

This constraint seems to be common on the HP PA/RISC anyway.  We had the same
problem using the Alsys compilers, which insisted on long-word alignment.  We
finally got it work by padding the fields out to fill 32-bit words.  If that
won't work for you, you may have to try your own masking fields.  But, it looks
like you have room to do some padding.

:    for ICD_IRG_010_Corrected_Input_Type use
:       record at mod 8;
:       tBlock   at    0 range 0..63;
:       tMeasU20 at    8 range 0..63;
:       tOffsetU at   16 range 0..63;
:       Channel1 at   24 range 0..367;
:       Channel2 at   70 range 0..367;                    -- line 103
:       Channel3 at  116 range 0..367;                    -- line 104
:       Channel4 at  162 range 0..367;                    -- line 105
:       Channel5 at  208 range 0..367;
:    end record;

: Capt Britt Snodgrass           e-mail: britt@molokai.46tg.af.mil
:                                member: Team Ada & Team OS/2

Hope this helps.  Since we're both working for the same customer (well, the
Army and Air Force are on the same side once in a while ;-), and since we've
already done a similar port, there may be other things you can learn from us.
Feel free to contact us for more info on SUCCESSFULLY porting Ada from
9000/3xx to 9000/7xx computers, and even PCs! (despite rumors to the contrary,
we've done quite well at porting).

Mike Meier

Re: Ada Portability... NOT!

[Norman H. Cohen]

In article <3ap9st$1mv@hydra.Helsinki.FI>, holsti@cs.Helsinki.FI (Niklas
Holsti) writes: 

|>                                                      Apparently the
|> compiler on the former system lets a record rep spec override an
|> alignment specified for the component types, but the present compiler
|> does not let you do that.

If this is the case, the original compiler is remiss.  A compiler must
reject representation clauses that it does not obey, and there is no way
to obey the given self-contradictory set of representation clauses.

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

Re: Ada Portability... NOT!

[Keith Thompson]

In <3alalm$9di@gnat.cs.nyu.edu> dewar@cs.nyu.edu (Robert Dewar) writes:
> It is probably a reasonable implementation choice to restrict reals to be
> on a properly aligned boundary, since it is an annoying amount of fiddling
> to deal with unaligned floating-point stuff, and yes, of course most 
> processors *do* require floating-point values to be aligned. When you use
> rep clauses you are definitely wandering into the area of implementation
> dependent non-portable constructs (most appropriately, since one of the
> functions of rep clauses is to deal with special target dependent
> requirements).
> 
> There is certainly no *requirement* that an implementation reject these
> declarations on a RISC machine, the code generator could generate the
> code to fiddle around and copy the value. Is it a good idea to do this
> behind the scenes? Not clear. Suppose a user just casually wrote rep
> clauses to pack the data in a way that worked fine on one machine but
> generated long inefficient sequences of code on another, do you want
> to be allowed or stopped? Either answer is possible.

I've just thought of a couple of ways an implementation could handle
this that might have some chance of satisfying everybody.

1. By default, provide a "reasonable" level of support for representation
   clauses.  For example, one might allow a floating-point component
   to be aligned on any boundary that allows it to be accessed with a
   single instruction (4 or 8 bytes).  Alignments that require fancier
   access code (e.g,. loading the value a byte at a time into a register
   or using bit-shifting) would be rejected -- unless a special pragma is
   given to allow it.  It occurs to me that such a pragma already exists:
   pragma Pack.

   For example:

      type Rec1 is
	 record
	    ...
	    F: Float;
	 end record;
      for Rec1 use
	 record
	    ...
	    F at 1 range 0 .. Float'Size - 1;	-- byte-aligned, rejected
	 end record;

      type Rec2 is
	 record
	    ...
	    F: Float;
	 end record;
      pragma Pack(Rec2);			-- permit tighter packing
      for Rec2 use
	 record
	    ...
	    F at 1 range 0 .. Float'Size - 1;	-- byte-aligned, permitted
	 end record;

   One could argue that this is an abuse of the semantics of pragma Pack,
   but I *think* the current definition is vague enough to allow it.

2. Similar to the above, but the compiler issues a warning (or
   informational message) for representations that require fancy
   access code.  The addition of a pragma Pack might suppress the
   warning message, reduce its severity from warning to informational,
   or whatever.

I don't know of any existing compiler that does this, including ones
I've worked on.

I've also often thought it would be nice if pragma Pack took an optional
second argument to specify how enthusiastically the compiler should
perform packing.  For example, pragma Pack(Some_Type) might ask the
compiler to pack to byte alignment, while pragma Pack(Some_Type, Dammit),
might ask it to pack to bit alignment.  (Note that an implementation
may not legally add arguments to an existing language-defined pragma.)

Whaddya think?

-- 
Keith Thompson (The_Other_Keith)  kst@alsys.com
TeleSoft^H^H^H^H^H^H^H^H Alsys, Inc.
10251 Vista Sorrento Parkway, Suite 300, San Diego, CA, USA, 92121-2718
/user/kst/.signature: I/O error (core dumped)

Re: Ada Portability... NOT!

[Robert Dewar]

"Whaddya think?"

I think it's an abuse of the semantics of pragma Pack :-)

Re: Ada Portability... NOT!

[Michael J. Meier]

Keith Thompson (kst@alsys.com) wrote:

: I've just thought of a couple of ways an implementation could handle
: this that might have some chance of satisfying everybody.

: 1. By default, provide a "reasonable" level of support for representation
:    clauses.

: 2. Similar to the above, but the compiler issues a warning (or
:    informational message) for representations that require fancy
:    access code.  The addition of a pragma Pack might suppress the
:    warning message, reduce its severity from warning to informational,
:    or whatever.

: I don't know of any existing compiler that does this, including ones
: I've worked on.

: I've also often thought it would be nice if pragma Pack took an optional
: second argument to specify how enthusiastically the compiler should
: perform packing.  For example, pragma Pack(Some_Type) might ask the
: compiler to pack to byte alignment, while pragma Pack(Some_Type, Dammit),
: might ask it to pack to bit alignment.  (Note that an implementation
: may not legally add arguments to an existing language-defined pragma.)

: Whaddya think?

It all looks like the start of something very useful.  Of course, we'd have
to define a different pragma.  But, the idea of being able to construct
reasonably portable rep-specs seems like it should be do-able.  While Ada 94
(95?) seems to go part way, it seems there should be some means along the
lines that you describe that would support portability.  After all, it seems
that we always seem to do the same transformations when we port from VAX to
680x0 to x86 to various flavors of RISC (to VLIW?), whether in Ada or C/C++.
So why not support these transformations directly in the language (or at
least the language implementation).  As a user of Alsys products (and possible
future user of Verdix/Rational products), I'd be especially interested in
hearing what these companies might do to support this concept.  Of course, I
recognize that GNAT is targeted to a non-embedded market so that it would have
less need to be concerned with such extensions.

Re: Ada Portability... NOT!

[R_Tim_Coslet]

Keith Thompson (kst@alsys.com) wrote:

: perform packing.  For example, pragma Pack(Some_Type) might ask the
: compiler to pack to byte alignment, while pragma Pack(Some_Type, Dammit),
: might ask it to pack to bit alignment.  (Note that an implementation
: may not legally add arguments to an existing language-defined pragma.)

: Whaddya think?

PRAGMA Packing(Some_Type, Alignment_Size);

PRAGMA Packing(Bit_Array_Typ, 1);           -- packing alignment 1 bit
PRAGMA Packing(Another_Typ, 8);             -- packing alignment 8 bits
PRAGMA Packing(One_More_Typ, Integer'Size); -- packing alignment integer size

                                        R. Tim Coslet

Usenet: R_Tim_Coslet@cup.portal.com
        technology, n.  domesticated natural phenomena