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=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,efbcb7a47025db16 X-Google-Attributes: gid103376,public From: dewar@merv.cs.nyu.edu (Robert Dewar) Subject: Re: Effort to Port TSG to Ada-95 and How Fast it Ran in Gnat Date: 1997/02/19 Message-ID: X-Deja-AN: 220090971 References: <5efjta$jlm@top.mitre.org> Organization: New York University Keywords: Ada-95, gnat, port, conversion, optimization, program_error Newsgroups: comp.lang.ada Date: 1997-02-19T00:00:00+00:00 List-Id: 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.