* ada portability
@ 1990-11-14 14:47 Claus Franzkowiak
0 siblings, 0 replies; 12+ messages in thread
From: Claus Franzkowiak @ 1990-11-14 14:47 UTC (permalink / raw)
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
--
^ permalink raw reply [flat|nested] 12+ messages in thread
* Ada portability
@ 1990-11-16 17:09 "", Mats Weber
1990-11-19 23:19 ` Robert I. Eachus
0 siblings, 1 reply; 12+ messages in thread
From: "", Mats Weber @ 1990-11-16 17:09 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Ada portability
1990-11-16 17:09 Ada portability "", Mats Weber
@ 1990-11-19 23:19 ` Robert I. Eachus
0 siblings, 0 replies; 12+ messages in thread
From: Robert I. Eachus @ 1990-11-19 23:19 UTC (permalink / raw)
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...
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Ada Portability
@ 1990-11-15 17:26 Ed Knoll @(719)593-3762
0 siblings, 0 replies; 12+ messages in thread
From: Ed Knoll @(719)593-3762 @ 1990-11-15 17:26 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Ada portability
@ 1990-11-14 17:04 David Emery
0 siblings, 0 replies; 12+ messages in thread
From: David Emery @ 1990-11-14 17:04 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* ada portability
@ 1990-11-14 14:27 Claus Franzkowiak
0 siblings, 0 replies; 12+ messages in thread
From: Claus Franzkowiak @ 1990-11-14 14:27 UTC (permalink / raw)
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
--
^ permalink raw reply [flat|nested] 12+ messages in thread
* ada portability
@ 1990-11-14 14:19 Claus Franzkowiak
0 siblings, 0 replies; 12+ messages in thread
From: Claus Franzkowiak @ 1990-11-14 14:19 UTC (permalink / raw)
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
--
^ permalink raw reply [flat|nested] 12+ messages in thread
* ada portability
@ 1990-11-14 14:16 Claus Franzkowiak
1990-11-17 4:09 ` Ted Holden
0 siblings, 1 reply; 12+ messages in thread
From: Claus Franzkowiak @ 1990-11-14 14:16 UTC (permalink / raw)
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
--
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: ada portability
1990-11-14 14:16 Claus Franzkowiak
@ 1990-11-17 4:09 ` Ted Holden
0 siblings, 0 replies; 12+ messages in thread
From: Ted Holden @ 1990-11-17 4:09 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* ada portability
@ 1990-11-14 14:09 Claus Franzkowiak
1990-11-15 14:10 ` ryer
0 siblings, 1 reply; 12+ messages in thread
From: Claus Franzkowiak @ 1990-11-14 14:09 UTC (permalink / raw)
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
--
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: ada portability
1990-11-14 14:09 Claus Franzkowiak
@ 1990-11-15 14:10 ` ryer
0 siblings, 0 replies; 12+ messages in thread
From: ryer @ 1990-11-15 14:10 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: portability problems
@ 1989-12-16 20:03 William Thomas Wolfe, 2847
1989-12-20 4:17 ` ARTEWG Bruce Jones
0 siblings, 1 reply; 12+ messages in thread
From: William Thomas Wolfe, 2847 @ 1989-12-16 20:03 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* ARTEWG
1989-12-16 20:03 portability problems William Thomas Wolfe, 2847
@ 1989-12-20 4:17 ` Bruce Jones
1989-12-22 12:29 ` Ada Portability Ed Matthews
0 siblings, 1 reply; 12+ messages in thread
From: Bruce Jones @ 1989-12-20 4:17 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Ada Portability
1989-12-20 4:17 ` ARTEWG Bruce Jones
@ 1989-12-22 12:29 ` Ed Matthews
0 siblings, 0 replies; 12+ messages in thread
From: Ed Matthews @ 1989-12-22 12:29 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~1990-11-19 23:19 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1990-11-14 14:47 ada portability Claus Franzkowiak
-- strict thread matches above, loose matches on Subject: below --
1990-11-16 17:09 Ada portability "", Mats Weber
1990-11-19 23:19 ` Robert I. Eachus
1990-11-15 17:26 Ada Portability Ed Knoll @(719)593-3762
1990-11-14 17:04 Ada portability David Emery
1990-11-14 14:27 ada portability Claus Franzkowiak
1990-11-14 14:19 Claus Franzkowiak
1990-11-14 14:16 Claus Franzkowiak
1990-11-17 4:09 ` Ted Holden
1990-11-14 14:09 Claus Franzkowiak
1990-11-15 14:10 ` ryer
1989-12-16 20:03 portability problems William Thomas Wolfe, 2847
1989-12-20 4:17 ` ARTEWG Bruce Jones
1989-12-22 12:29 ` Ada Portability Ed Matthews
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox