sdl@herbrand.Inference.Com (Daniel Lee) (12/16/89)
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.combillwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ) (12/17/89)
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?)