Re: Ada News Brief

[dewar@merv.cs.nyu.edu (Robert Dewar)]

Keith said

"I'm not sure where this statement came from, but it's not quite correct.
Ada 95 is very nearly upward compatible with Ada 83, so *most* correct
and portable Ada 83 code is valid Ada 95 code with the same semantics.
In one study I've read about, an program consisting of several tens of
thousands of lines of Ada 83 code, which had not been written with Ada 95
in mind, required no changes whatsoever.  Porting a program from Ada 83
to Ada 95 is typically no more difficult than porting from one compiler
to another.
"


There are other potential difficulties in porting from Ada 83 to Ada 95
in practice besides the known incompatibilities:

1. Bugs in the original compiler that it did not catch. We have run into
   instances of this with every Ada 83 compiler we have dealt with so far.

2. Bugs in the new Ada 95 compiler. As OCS systems pointed out, for at 
   least some time to come, every Ada 95 compiler will have some bugs.
   Indeed, given that we have had a fair amount of experience in running
   old Ada 83 compilers that are supposedly mature and finding bugs, maybe
   some time to come will be a while. Basically for any modern powerful
   programming language, it is likely that compilers have SOME errors.
   What one hopes is that this source of problems is small compared to
   other problems, and that is what we have found to be the case with
   GNAT so far, and I have heard similar anecdotal evidence for other
   Ada 95 compilers.

3. Rep clauses not implemented the same way. For example, last I knew,
   Ada Magic uses sparse array structures where the index type is an
   enumeration type with holes. GNAT used to do so as well, but we found
   that this generated critical incompatibilities with old Verdix code,
   and changed GNAT accordingly. There are *many* other cases of this
   kind of problem. Over time, this has been one of the most difficult
   areas to deal with, though by now, GNAT implements almost all the
   rep clauses we have run into.

4. Code that depends on implementation dependent details. For example, one
   of our large customers had a heck of a time tracking down a "bug" which
   turned out to be a case where a packed array of length (1 .. 32) of
   booleans was mapped to an external hardware address. The Verdix compiler,
   perfectly reasonably, loaded the entire 32-bit word to test one bit. GNAT
   perfectly reasonably, loaded only the byte containing the bit to be tested.
   Normally these two approaches would be identical, but their hardware could
   not handle byte addressing for this address. We "fixed" GNAT to do a word
   access in this case, but it was not of course a bug in GNAT.

5. Use of library packages, if code uses some vendor supplied package (e.g.
   Starlet on DEC), then of course porting it may be tricky.

6. Use of preprocessors that are either not available, or supported 
   differently in the new Ada 95 environment. We have prepared a
   preprocessor that is available with the current version of GNAT that
   can be used to handle some of these cases.

7. Use of pragmas and attributes not supported in the new compiler. For
   example, when porting DEC code, there are some programs which use the
   DEC pragmas and attributes (e.g. Import_Valued_Procedure pragma or
   the Null_Parameter attribute) that can be hard to translate. That is
   why we have implemented all these pragmas and attributes in GNAT.

That's not an exhuastive list, but the point is that the incompatibilities
between Ada 83 and Ada 95 have NOT proved to be a major issue in porting
existing Ada 83 code. It should also be said that our experience with GNAT
is that we have been able to port a number of large programs (in the several
hundred thousands of lines range) from Ada 83 to GNAT successfully, with a
very reasonable amount of effort and as we go, this gets easier. Interestingly
the reason it gets easier is not because of GNAT becoming generally more
solid (issue 2 above), but rather because we keep implementing new
functionality that alleviates other problems from the above list. In practice
at this stage, we find that compiler bugs are a relatively small part of
the porting issue.

And yes, Keith is still right that the effort to port from Ada 83 to Ada 95
is comparable to porting from one Ada 83 to another Ada 83. This is the
"distance" test that was established as a design requirement for the Ada 95
effort, and in practie, this criterion seems to have been met, which means
that operationally Ada 95 is upwards compatible with Ada 83.

However, no one should tell anyone that it is zero effort to move from Ada 83
to Ada 95. This is false, just as false as telling someone that it is zero
effort to move from one Ada 83 compiler to another Ada 83 compiler. Sure,
if a program has been *very* carefully written, and avoids implementation
dependent features, it may be highly portable, but the real world of large
scale applications is not in this category.

Ada programs are typically highly portable, but it is important not to
oversell this feature. I once heard the project director for the IBM
air traffic control system say that Ada 95 must guarantee that their
application move without changing a single line of code. The mere fact
that someone could state this obviously unrealistic requirement worried
me at the time, since it seems to me that anyone working with large
Ada applications should have a more realistic view.