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

[Claus Franzkowiak]

   How much portability can I expect from an Ada program, given two different 
computers with two different operating systems and two different compiler 
vendors.  Exclude real-time programming from this assumption.  I am using
validated compilers only.

claus franzkowiak
cfranz@wrdis01.af.mil
cfranz@wrdis01.arpa
-- 

ada portability

[Claus Franzkowiak]

   How much portability can I expect from an Ada program, given two different 
computers with two different operating systems and two different compiler 
vendors.  Exclude real-time programming from this assumption.  I am using
validated compilers only.

claus franzkowiak
cfranz@wrdis01.af.mil
cfranz@wrdis01.arpa
-- 

ada portability

[Claus Franzkowiak]

   How much portability can I expect from an Ada program, given two different 
computers with two different operating systems and two different compiler 
vendors.  Exclude real-time programming from this assumption.  I am using
validated compilers only.

claus franzkowiak
cfranz@wrdis01.af.mil
cfranz@wrdis01.arpa
-- 

ada portability

[Claus Franzkowiak]

   How much portability can I expect from an Ada program, given two different 
computers with two different operating systems and two different compiler 
vendors.  Exclude real-time programming from this assumption.  I am using
validated compilers only.

claus franzkowiak
cfranz@wrdis01.af.mil
cfranz@wrdis01.arpa
-- 

ada portability

[Claus Franzkowiak]

   How much portability can I expect from an Ada program, given two different 
computers with two different operating systems and two different compiler 
vendors.  Exclude real-time programming from this assumption.  I am using
validated compilers only.

claus franzkowiak
cfranz@wrdis01.af.mil
cfranz@wrdis01.arpa
-- 

Re: Ada portability

[David Emery]

The answer to your question is indeterminate.  It is very possible to
write completely non-portable Ada, and it is possible to write code
that ports simply via recompilation.  Nissen & Wallis Ada Style Guide
(Cambridge University Press, earlier version published in Ada Letters
vol I, #3, Mar/Apr 1982) shows how to achieve portable code.  

But, you'll never fit SDI onto an IBM PC, no matter how well it's
written.  Most of the real portability problems are design problems,
not coding problems.  See Karl Nyberg and my paper in Ada-Europe 1989
(also Cambridge University Press), "Observations on Portable Ada
Systems".

				dave emery
				emery@aries.mitre.org

Re: ada portability

[ryer]

You can expect to get out as much as you put in.  For example, if you
just declare variables to be of built-in types, then behavior may vary
on machines/compilers with different hardware.  If you declare variables
with range and precision constraints to specify exactly what you need,
then all compilers must give you the same behavior.  If you use compiler
or operating-system unique packages (e.g. DEC's package STARLET), compiler-
unique pragmas, etc., then you will loose portability.  If you use
representation specifications to do bit twiddling, don't count on much
portability.  If you write your program carefully, avoiding machine
dependencies, OS dependencies, and unique compiler features, you should
get excellent portability.  The only problem will be different bugs
in different compilers, and this should not be significant.

Ada *enables* you to build very portable software.  Ada also enables you
to write very low-level, machine dependent software.  Both capabilities
can be neccessary.  If you have to pack some bits into a hardware defined-
message packet, and use the operating system to transmit it over a 1553 bus,
then you need to be able to write non-portable code, and Ada will let you.
There are several guidline documents that will help you write code that
is 100% portable.

Hope that helps

Mike Ryer
Intermetrics

Re: Ada Portability

[Ed Knoll @(719)593-3762]

The issue of portability is indeterminate if it is not planned for.  There 
are some aspects of the language and of some of the compilers that can make it 
difficult.  However, we have had some fairly decent success.  For example:

  A group I was working with was supporting two programs simultaneously.  One
  job was essentially a subset of the other with about 20% unique material.
  They were both hosted on the same target (embedded processor), but each 
  program was using a different run-time library.  This was the target 
  environment.

  On the host, we were using two different compilers.  One would generate
  code for the host and the target, the other just generated code for the
  host.  The host only compiler was somewhat faster and had a better host
  debugger.

  In addition, there was a large simulation (written in FORTRAN and Pascal)
  that emulated different aspects of the environment and the system.  We
  wished to test some of the subsystems of the Ada code by substituting
  them for their counterparts in the simulation.  At the same time we were
  putting together an environment where the entire applications software
  would be driven by the environment and hardware components of that
  simulation.

  We constructed an OS frontend to hide the differences between the two
  run-times for the target and we built a body for the frontend that would 
  allow the applications to run on the host.  The host only Ada compiler
  did not include 'long_int' in the standard package because 'integer' was
  long to begin with.  A package was constructed which contained a 'long_int'
  declaration for the host; the same package contained nothing for the target.
  This package was 'with'ed and 'use'ed by everyone.  Driver packages were 
  written for the different interfaces with the simulation.

  Library organization controlled how we constructed the different versions.

  Summary: Compilers             - 2
           Platforms             - 2 (target and host)
           Operating Systems     - 3 (two target and host emulation)
           Execution Environment - 5 (standalone host, subsystem w/ simulation, 
                                      entire system w/ simulation, two targets)

Not all code was (or could) be evaluated in every environment, but much of 
it was with very few portability problems.  It did take some planning and 
some rework, but very cost effective overall.

-------------------------------------------------------------------------------

Edward L. Knoll                     Disclaimer:  If my company doesn't trust
Texas Instruments                                my judgement, why am I working
5825 Mark Dabling Blvd                           for them?
Colorado Springs, Colo. 80919
(719) 593-5182

knoll@coopn1.csc.ti.com

Ada portability

["", Mats Weber]

In reply to what Dave Emery wrote, I must add that even if you write code 
with portability in mind, you will probably run into compiler quality 
problems if your code contains generics.
We have had major problems in this area which until now have made it 
impossible to port some quite small applications from VAX Ada to Unix with 
ANY compiler available on Unix.

In my opinion, the only two compilers I know that deserve the "validated" 
label are Rational and Vax Ada.


Mats Weber
Swiss Federal Institute of Technology
EPFL DI LGL
1015 Lausanne
Switzerland

E-mail : madmats@elcgl.epfl.ch
phone  : +41 21 693 52 92
fax    : +41 21 693 39 09

Re: ada portability

[Ted Holden]

In article <522@wrdis03.af.mil> cfranz@wrdis01.af.mil (Claus Franzkowiak) writes:

>   How much portability can I expect from an Ada program, given two different 
>computers with two different operating systems and two different compiler 
>vendors.  Exclude real-time programming from this assumption.  I am using
>validated compilers only.

Consider the following lament from the Adawoe electronic bulletin board,
maintained by the Ada community for the purposes those who enjoy laughing
at them:

 
   Complaint #0365 

   Problem:

   Implementation Options Lead to Non-Portability and

   Non-Reusability.

 

   Discussion:     The LRM allows many implementation
   options and this freedom has lead to numerous
   "dialects" of Ada.  As programs are written to rely on
   the characteristics of a given implementation,
   non-portable Ada code results.  Often, the programmer
   is not even aware that the code is non-portable,
   because implementation differences amy even exist for
   the predefined language features.  Further, it is
   sometimes not impossible to compile an Ada program with
   two different implementations of the same vendor's
   compiler.

 

   Another kind of non-portability is that of the programmer's
   skills,  The user interfaces to Ada compilers have become so
   varied that programmers find it very difficult to move from
   one Ada implementation to another,  Not only does the
   command line syntax vary, but so do program library
   structures, library sharability between users, compiler
   capabilities, capacity limits. etc.

   Importance:     ESSENTIAL

   Current Workarounds:


   Significant amounts of code rewriting, recompilation, and
   testing must be done to get a given Ada program to compile
   and to run successfully using another compiler, if at all
   possible, even on the same host-target configuration.  It
   is very difficult to write a truly portable Ada program.

   Another possible solution to porting an Ada program is for
   a customer to carefully choose a compiler to suit the given
   Ada program, or perhaps collaborate with a vendor to tailor
   the compiler to suit these needs.

   Significant amounts of programmer retraining must occur
   when a different Ada compiler is used.

......................................................

But don't despair;  Ada9x is just around the corner.  About 1997.

Ted Holden
HTE

 

 

Re: Ada portability

[Robert I. Eachus]

In article <901116180937.45k@sic.epfl.ch> MADMATS@ELCGL.EPFL.CH ("", Mats Weber) writes:

   We have had major problems in this area which until now have made it 
   impossible to port some quite small applications from VAX Ada to Unix with 
   ANY compiler available on Unix.

   In my opinion, the only two compilers I know that deserve the "validated" 
   label are Rational and Vax Ada.

     Please!!  If everyone is out of step but you, maybe you are the
person who is out of step...

     More seriously, for many years there have been two "mechanisms"
for implementing generics, and DEC has been the only major player
using the generics as macros approach.  I used to joke that (since I
heavily use generics in my programs, and preferred Verdix for
development) I had never written an Ada program that compiled and ran
using the DEC compiler.  This does not mean that my programs or the
DEC compiler were not legal Ada, but that I kept running in to the
Godel Incompleteness problem: (Godel translated: Any compiler for any
useful language must either not accept all legal programs, or must
accept some illegal programs.)

     A similar example is the way variant records are implemented.  To
simplify drastically, Alsys uses hidden pointers for records contaning
unconstrained arrays, while Verdix uses allocates the maximum size.
(Both compilers actually have available tuning parameters, and...)
Well written programs will compile and run on both compilers without a
hitch, but it is possible to construct programs which raise exceptions
on one of the two but not the other when run.  Is one implementation
better than the other?  Not in my opinion.

     With version 2.0,my understanding is that the DEC compiler is
much closer to the generic "mainstream." However, DEC is obviously not
going to intentionaly modify their compiler so that it refuses
programs that it accepted previously, so it will probably be the case
for a long time that programs will be harder to port from DEC to the
rest of the world than vice-versa.

     Just so that you don't get the wrong idea from all of this, I
have, as part of an evaluation of software capabilities, implemented a
system (missing the body a generic package) and gone into a
contractors facility and expected them to compile and execute my code
with a body for the package supplied by them.  In several cases, the
system compiled, linked and executed test cases without one line of
code changed.  Note that I did not know which systems it would be
compiled or run on when I wrote the code, and the (potential)
contractors had not seen my code in advance (or for that matter before
they ran it).

     And yes, when I tested my code, I explicitly tested it on several
systems, and as expected from my personal experience, the only one
which required signifcant modification was DEC Ada 1.5.  I was able to
come up with a DEC Ada and everybody else version.  Note again, I'm am
not saying that their impelmentation was wrong, illegal, or not Ada.
It just required be to rein in my generic nesting style to comply with
the limits of that implementation.

--

					Robert I. Eachus

with STANDARD_DISCLAIMER;
use  STANDARD_DISCLAIMER;
function MESSAGE (TEXT: in CLEVER_IDEAS) return BETTER_IDEAS is...