From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,c70bb16b3813e0fd
X-Google-Attributes: gid103376,public
X-Google-ArrivalTime: 1994-11-19 17:33:42 PST
Path: 
 nntp.gmd.de!xlink.net!howland.reston.ans.net!math.ohio-state.edu!magnus.acs.ohio-state.edu!csn!perez
From: perez@oldcolo.com (Carlos Perez)
Newsgroups: comp.lang.ada
Subject: Re: Ada Portability... NOT!
Date: 20 Nov 1994 01:33:42 GMT
Organization: Old Colorado City Communications (oldcolo.com - login "newuser")
Message-ID: <3am91m$d4v@news-2.csn.net>
References: <199411182104.PAA04854@mail.cs.utexas.edu>
NNTP-Posting-Host: oldcolo.com
X-Newsreader: TIN [version 1.2 PL2]
Date: 1994-11-20T01:33:42+00:00
List-Id: <comp.lang.ada>

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