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
Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!wuarchive!brutus.cs.uiuc.edu!apple!agate!ucbvax!herbrand.Inference.Com!sdl
From: sdl@herbrand.Inference.Com (Daniel Lee)
Newsgroups: comp.lang.ada
Subject: Ada portability and conditional compilation
Message-ID: <8912160225.AA08090@Herbrand.Inference.Com>
Date: 16 Dec 89 02:25:08 GMT
Sender: usenet@ucbvax.BERKELEY.EDU
Organization: The Internet
List-Id: <comp.lang.ada>

In a previous message, I described how we are using cpp to preprocess Ada source files
with C macros (#if, #endif, etc.) embedded.  The problem is that although Ada is
designed for portability, it is not portable enough.  In this message, I would like to
point out which Ada features are not portable and thus subject to conditional compilation.

1. binding

If you have experiences in developing an Ada binding, you would probably know how hard
it is to write portable binding code for multiple compilers running on multiple 
platforms.

  i.   Pragmas for importing and exporting subprograms are not portable.
  ii.  Parameter passing mechansim both for Ada call-in and Ada call-back is not 
       standardized.
  iii. Because of ii, a mechanism for string conversion between Ada and another 
       language (e.g. C) is not portable.

2. math library

Most Ada compilers come with a math library.  They are usually very similar,
but slightly different because there exists no standard for it.

3. operating system escape

We implemented a function MY_SYSTEM that calls out to the O/S.
For example,

  function MY_SYSTEM (ARG : STRING) return BOOLEAN;

  STATUS : BOOLEAN;
  STATUS := MY_SYSTEM("ls -l");

Obviously, implementation of this function cannot be portable.

4. pragmas

The pragma syntax in general is not standardized by LRM.

5. STANDARD.INTEGER, STANDARD.FLOAT, etc.

LRM does not enforce any standard for INTEGER, FLOAT,
LONG_INTEGER, LONG_FLOAT, SMALL_INTEGER, SMALL_FLOAT, etc.
Our tool supports 32-bit integers and 64-bit floats internally.
We define INTEGER_TYPE and FLOAT_TYPE as subtypes
of whatever a compiler define as such.

#if VERDIX
   subtype INTERNAL_FLOAT_TYPE is FLOAT;  
#endif
#if ALSYS || VMS
   subtype INTERNAL_FLOAT_TYPE is LONG_FLOAT;  
#endif
#if VERDIX || VMS
   subtype INTERNAL_INTEGER_TYPE is INTEGER;
#endif
#if ALSYS
   subtype INTERNAL_INTEGER_TYPE is LONG_INTEGER;
#endif

6. rep spec.

  As Bill Wolfe pointed out, the rep spec boundary alignment problem 
  can be solved by defining a global varable as follows:
  
#if VERDIX | VMS
   WORD : constant := 4;   -- number of storage units per 32-bit word
#endif

#if ?  -- we have not encountered this yet
   WORD : constant := 2;   -- number of storage units per 32-bit word
#endif

   for DATA use
   record
      FOO	at 0*WORD range 0..15;
      BAR 	at 0*WORD range 16..31;
      FEE 	at 1*WORD range 0..15
      BEE 	at 1*WORD range 16..31;
   end record;

  Another problem with rep spec is that bit-level rep spec does not
  work on some compilers (e.g. Verdix 5.5t on a Sun 3).  Therefore,
  you have to maintain at least two versions, one with no rep spec
  and one without it.

				Daniel Lee
				Inference Corporation
				lee@inference.com or sdl@inference.com