Re: Effort to Port TSG to Ada-95 and How Fast it Ran in Gnat

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

Some comments on Michael's porting experience

(my comments are marked by -->)

(3) In one place, a string had to be identified as type string using
qualified expressions because Ada-95 thought it MIGHT a be wide_string.

   --> A known incompatibility between Ada 83, and Ada 95. The exact
       case you encountered would be of interest.

(4) Redundant subtype indicators were needed around some expressions
controlling a CASE statement, e.g.
   x: my_subtype;
   case my_subtype (x) is

   --> sounds like a possible bug, but one would have to see the
       exact case.

(5) Certain packages and variable names had to be renamed to
permit gnat chopping, because the gnat rule gave them the same name
(for example, try gnatchopping the serial port interrupt handler that
comes in the EXAMPLES directory of the Alsys compiler).

   --> Obviously this can only occur in a DOS-like environment with
       limited length of names, otherwise of course names never clash.
       In the latest version of GNAT (3.10), gnatchop pays attention
       to the Source_File_Name pragmas in gnat.adc, so this is another
       way of doing things without chnaging the source.

(6) Some variables and nested functions had to be renamed when they
had the same names as variables, functions, packages, and types in
which they were nested.

   --> This sounds like a bug in the original compiler, but again,
       one would have to see the exact code to be sure.

(8) The tiny bit of floating point computations (used for computing
statistics at the very end) had to have the TRUNCATE function reprogrammed
(actually simplified to RETURN FLOATES'TRUNCATION (X)). This was because
Ada-95 does rounding simpler, that is, different from Ada-83.

   --> The comment here is probably wrong. There is no requirement that
       Ada 95 differ from Ada 83 here, it sounds like the original code
       was inappropriately relying on implementation dependent choices,
       or that there was a bug in the Ada 83 compiler.

(9) A floating point assertion failed (an impossible error) in which
a particular number was both > and <= another number at the same time.
This only happened on the Sparc, not in the same code on a  pc, nor on
the same code on the Verdix/Sparc Ada-83 compiler. It required an extra
epsilon comparison to be made instead of using the built-in <= operator.

   --> If two floating point numbers A and B are both non-model numbers
       if is perfectly possible for all of

          A = B
          A < B
          A <= B
          A > B
          A >= B

       to be true. Code that assumes otherwise is flawed.

(10) The packages had internal regression tests, run at elaboration
time. Many of these called other packages. The Ada-83 compilers figured
out a valid elaboration order, which was easy because there were no
complications like recursion, looping, inputs from the user,
generic instantiations with varying subtypes, or anything else which
would require run-time determination of elaboration order. The following
algorithm would work: if the regression test invoked at the bottom
of a package calls a procedure in a different package, then please
elaborate that package body before the calling package body. However,
Ada-95 permits (and gnat seem to demand) a compiler to get confused
whenever there is an elaboration order consistent with the WITH order,
but inconsistent with the regression test calling order.

      --> This is confused. Once again, you are using Ada 83 and Ada
          95 as though you are talking about language features. There
          are no differences between Ada 83 and Ada 95 in choice of
          elaboration order. Obviously the old program was flawed, it
          should have had pragma Elaborate's but instead was relying
          on the order chosen by the compiler.

          It is not generally possible to choose a correct elaboration
          order statically at compile time in either Ada 83 or Ada 95.
          It is easily shown to be equivalent to the halting problem.
          Of course compilers may try harder or less hard to guess a
          good order. GNAT now chooses a more likely correct order
          than it used to, but the danger is, as shown by this case,
          invalid programs will escape the programmer's attention.

          GNAT how has a -h (horrible elaboration order) option in
          the binder which forces a worst case choice of elaboration
          order, which is useful for smoking out cases like this

The beautiful testing philosophy, to always elaborate a regression test
inside each package body, is demised forever, because it is possible
to program software that is extremely difficult or impossible to
determine the elaboration order. The new philosophy has to be to
invoke tests externally from the packages being tested.

      --> If this beautiful philosophy cannot easily be fixed up using
          pragma Elaborate, then it is not beautiful, it is badly flawed
          incorrect Ada!

(11) An extra seek had to be put into the stream_io open for append on
the PC because it did not automatically seek the end of the file,
tho it did overwrite the existing file rather than open a new file.

      --> That sounds like another bug, but again it is hard to be sure

--> It is often the case, as in the above description, that many of the
porting problems are caused by incorrect code in the aplication being
ported. This corresponds to our experience with porting some large codes.