From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE
	autolearn=no autolearn_force=no version=3.4.4
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!lll-lcc!ames!ucbcad!ucbvax!ESTEC.BITNET!WMORTENS
From: WMORTENS@ESTEC.BITNET
Newsgroups: comp.lang.ada
Subject: Reply to: How Portable ?
Message-ID: <8612310516.AA06584@ucbvax.Berkeley.EDU>
Date: Mon, 22-Dec-86 10:55:52 EST
Article-I.D.: ucbvax.8612310516.AA06584
Posted: Mon Dec 22 10:55:52 1986
Date-Received: Wed, 31-Dec-86 04:04:28 EST
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
List-Id: <comp.lang.ada>

I have some sympathy for the 'resident skeptics' of E. Hauser, based
on an experience we had in 1985:

In 1985 ESA issued a research contract to evaluate the use of Ada
for space applications. The work consisted of redesigning a 5000
lines FORTRAN77 program to Ada. The program simulated the dynamics
and controls of the GIOTTO spacecraft.

After design and testing of the Ada version, the last workpackage of
the contract contained a study of the portability of the Ada code.
Since the Ada version was developed by Ada 'wizards' and the LRM etc.
gives high hopes for portability, we did not expect much trouble, and
allocated one full working day per compiler for testing.

The program was developed using the DG/Rolm Ada compiler, and was attempted
ported to SIX other VALIDATED compilers and two pre-release compilers.

     ********************************************
     *   NONE OF THE EIGHT ADA COMPILERS        *
     *   COULD COMPILE AND RUN THE PROGRAM |||| *
     ********************************************

The VALIDATED compilers tested were:
    DEC, DDC, ALS(1.6), Telesoft(2.1), Karlsruhe(1.3), Alsys
And the pre-releases :
    Gould/SEL, Alsys/Apollo.

The ONLY compiler, which could produce a running program after minor
modifications only, was the DEC compiler (the COUNT attribute of task
failed to increment, and math procedures were named differently).

ALL (ALL|) the others failed for all sorts of reasons, such as:
pure crash of the compilers, 'heap full' problems, missing essential
features (one compiler did e.g. not support instantiation of generic
packages, that contains task declarations). The problems were such that
major redesigns in order to work-around the problems would be required.
In NO case the problem could be identified as a design error in the
original Ada code (which was running without problems on the DG).

Conclusions ? --- I refrain from the obvious conclusions, and just
qoute what the compiler designers have been telling us over the years:
'A better Ada compiler will come out soon next year'

Uffe K. Mortensen,
The European Space Agence,  ESA/ESTEC.