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-21 07:40:08 PST Newsgroups: comp.lang.ada Path: nntp.gmd.de!urmel.informatik.rwth-aachen.de!newsserver.rrzn.uni-hannover.de!aix11.hrz.uni-oldenburg.de!nordwest.germany.eu.net!pophh!Germany.EU.net!wizard.pn.com!sundog.tiac.net!news.kei.com!news.mathworks.com!europa.eng.gtefsd.com!gatech!swrinde!pipex!uunet!psinntp!ss3!mjmeie From: mjmeie@ss3.magec.com (Michael J. Meier) Subject: Re: Ada Portability... NOT! Message-ID: Organization: Magnavox Electronics Systems Company X-Newsreader: TIN [version 1.2 PL2] References: <199411182104.PAA04854@mail.cs.utexas.edu> Date: Mon, 21 Nov 1994 15:40:08 GMT Date: 1994-11-21T15:40:08+00:00 List-Id: 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 : : 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