edm@vrdxhq.verdix.com (Ed Matthews) (12/22/89)
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
cfranz@wrdis01.af.mil (Claus Franzkowiak) (11/14/90)
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 --
emery@D74SUN.MITRE.ORG (David Emery) (11/15/90)
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
ryer@inmet.inmet.com (11/15/90)
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
knoll@coopn1.csc.ti.com (Ed Knoll @(719)593-3762) (11/16/90)
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.comMADMATS@ELCGL.EPFL.CH ("", Mats Weber) (11/17/90)
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
ted@grebyn.com (Ted Holden) (11/17/90)
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
eachus@linus.mitre.org (Robert I. Eachus) (11/20/90)
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...