Ada portability and conditional compilation

Ada portability and conditional compilation

[Daniel Lee]

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

Re: Ada portability and conditional compilation

[William Thomas Wolfe, 2847]

From sdl@herbrand.Inference.Com (Daniel Lee):
> In this message, I would like to point out which Ada features 
> are not portable and thus subject to conditional compilation.

   The point about some aspects of Ada 83 software being necessarily
   non-portable is well-taken; but the question is: "Should we address
   the problem via conditional compilation, or by some other means of
   ensuring portability?".  

   Robert Munck has pointed out the flagrant abuses of conditional
   compilation and suggested that not having conditional compilation
   would promote better software engineering practice; it would seem
   that there are better ways of facilitating portability, such as 
   secondary standards, upgrading of SYSTEM and other required packages, 
   and so on.  
   
   Is there some fundamental reason why the use of these two mechanisms
   cannot reasonably address portability issues without introducing
   conditional compilation (Feel free to define "reasonably"...), or
   some benefits which might outweigh the high potential for abuse
   and the inability of compilers to perform optimizations on the basis
   of high-level semantics?  If so, maybe a preprocessing mechanism such
   as conditional compilation should be included in the Ada definition;
   otherwise, perhaps preprocessing is best left as an ad hoc response to
   the lengthy revision cycle. 
   
    
   Bill Wolfe, wtwolfe@hubcap.clemson.edu

   (P.S. Thanks to those who pointed out the rationale behind requiring 
         unique field names and the correct semantics of SYSTEM.NAME; now
         does anyone know why SYSTEM.NAME was not called SYSTEM.TARGET?)

Re: portability problems

[William Thomas Wolfe, 2847]

From sdl@herbrand.Inference.Com (Daniel Lee):
> 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.

   At Tri-Ada '89, Sholom Cohen told me that the Numerics Working group
   took about eight years to come up with a standard math package, and 
   that the Ada Run-Time Environment Working Group also required about
   eight years to come up with a standard run-time environment package.

   These should make it into Ada 9X, and should take care of some of the
   remaining portability problems.  Apparently there is quite a lot of  
   work involved in coming up with good solutions to these problems, but 
   progress is being made on these very important issues. 


   Bill Wolfe, wtwolfe@hubcap.clemson.edu
 

ARTEWG

[Bruce Jones]

In article <7475@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes:
>
>   At Tri-Ada '89, Sholom Cohen told me that the Numerics Working group
>   took about eight years to come up with a standard math package, and 
>   that the Ada Run-Time Environment Working Group also required about
>   eight years to come up with a standard run-time environment package.

>   These should make it into Ada 9X, and should take care of some of the
>   remaining portability problems.  

The ARTEWG's "standard" runtime environment package is called the Model
Runtime System Interface (MRTSI).  As the MRTSI only provides support for 
the existing Ada RM,  it is already in some sense "in" Ada 9x Since the 
MRTSI only specifies the interface between the Ada compiler and the Ada RTE,  
it is unlikely that it will be added to the RM during the Ada 9x process.

The MRTSI therefore does not solve any portability problems,  as we all
know that the green book is already completely portable. :>

Application developers,  especially those with real-time constraints,  face
many problems not addressed by either the green book or the MRTSI.  To meet 
these needs,  the ARTEWG is pursuing two parallel tracks;  we are contributing 
to the Ada 9x process,  and are continuing to develop the ARTEWG's set of 
"extensions" to the standard Ada RTE,  the Catalog of Interface Features and 
Options (CIFO).

The next version of the CIFO is in the process of being prepared.   Several
important topics remain under investigation and discussion,  including
task scheduling,  distributed Ada,  security,  multiprogramming,  and 
many more.  We expect this new version of the CIFO to appear long before
validated Ada 9x compilers,  and thus serve as a short-term solution to 
application needs.

BLATANT PLUG:  The next meeting of the ARTEWG is scheduled for January 30th
through February 2nd in sunny and warm Fort Lauderdale,  Florida.  Members
of the Ada community interested in contributing to the ongoing work of
the ARTEWG are more than welcome to attend the meeting.  Drop me some email
if you are interested in attending.

SECOND BLATANT PLUG:  Copies of the MRTSI,  the CIFO and the other
published ARTEWG documents are available.  Again,  drop me some email if
you are interested.

----------
Bruce Jones                               brucej@ssd.csd.harris.com, 
ARTEWG member and chubby programmer       jonesb@ajpo.sei.cmu.edu,
Harris Computers, Fort Lauderdale, FL     ..!uunet!hcx1!brucej

Ada Portability

[Ed Matthews]

In article <2387@hcx1.UUCP> brucej@hcx9.UUCP (Bruce Jones) writes:
>
>The MRTSI therefore does not solve any portability problems,  as we all
>know that the green book is already completely portable. :>

Yes, I take mine everywhere with me. :)

Merry Christmas, Happy Hanukkah, or Happy Whatever_You_Celebrate!
-- 

Ed Matthews                                                edm@verdix.com
Verdix Corporation Headquarters                            (703) 378-7600
Chantilly, Virginia

Ada portability and conditional compilation

[Daniel Lee]

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