Re: THAAD Study on Ada Viability

[Robert Dewar <robert_dewar@my-deja.com>]

In article <90nq6h$3l9$1@nnrp1.deja.com>,
  n_brunot@my-deja.com wrote:

> Today, NO Ada 95 compiler can fully replace our 5
> year old Ada83 compiler without severe regression.
> This is a fact ... and so compiler availability is
> a real concern.

Well it *might* be a fact, but I doubt you have
the data to support the claim. For example, you
certainly are not a customer of ACT or ACTE, so
your statement certainly does not include GNAT
Professional. Perhaps you are a customer of
OCS, Rational, Greenhills, Aonix, Irvine, DDC/I,
... (sorry if I forgot any), and can thus make a
fully informed statement for other compilers, but I
doubt it :-)

One thing that tends to happen with large legacy
codes is that they have been kicked, tuned, pushed,
and generally molested over the years to work well
with some legacy compiler and to circumnavigate bugs
in the old compiler. Then when you port to
ANY other compiler, you find five things:

1. Errors in the program that were not apparent in
the earlier use -- a very common case for example is
missing pragma Elaborate statements.

2. Implementation dependent stuff that happened to
work in some older compiler and works no longer.

3. Stuff that works only because of bugs in the old
compiler which are corrected in the new compiler.

4. Performance issues. Sometimes these are indeed
significant differences in performance. Other times
they simply reflect the fact that code has been tuned
to meet the particular behavior of another compiler.
One really nasty case we had of performance
degradation turned out to be a program which read the
value of an environment variable in the inner
computational loop of the program -- it read the same
variable over and over again -- and apparently VADS
cached the result so this rather peculiar programming
decision did not have much impact. When we moved the
read out of the loop, all was well again.

5. Finally you may indeed run into some problems and
bugs in the new technology. How much of a problem
that is will depend on how easy it is to work around
these problems, and how easily problems that cannot
be worked around can be fixed. That is of course a
function of the support you get from your vendor.

Certainly there are no bug free Ada 83 compilers.
Even DEC Ada, which I think most people would
consider to be one of the best Ada 83 compilers has
many bugs (we found quite a few serious ones as we
ported GNAT to VMS -- for example, there were some
tests in the DEC test suite that we failed because
the test was expecting the wrong thing :-)

Milage may vary of course, but our general experience
is that in porting large legacy codes at this stage
with GNAT Professional, although we certainly get
some cases of 5 (bugs in GNAT), they are usually
relatively easily dealt with, and the more serious
problems in moving to GNAT are in categories 1 and 2.
(elaboration problems are often very annoying, and
are almost entirely a matter of incorrect code that
happened to work before). Certainly there are some
cases where performance problems and other bugs are
significant and require work, but in most cases, this
is not the most significant porting issue
(although this presumes support from
us, and it is not so much of a surprise that Nicolas
Brunot runs into more troubles trying to do serious
work with the public version of GNAT).

Robert Dewar
Ada Core Technologies


Sent via Deja.com
http://www.deja.com/