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/20 Message-ID: X-Deja-AN: 220147659 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-20T00:00:00+00:00 List-Id: Some more followup on Michael's posts about porting experiences. I think posts like this can be very useful, and indeed we have certainly learned a lot from porting large programs in the million line range from various Ada 83 compilers to GNAT, but it is always risky to draw conclusions from porting one small (only 50K line) program, so here are some cuationary notes on Michael's recommendations, which come from our much more extensive experience with this kind of porting. (my responses are idented, original recommendations preceded by >) > 1. Before porting an Ada-83 application to Ada-95, you might wish to > port it to one or two other Ada-83 compilers to get rid of the compiler > dependencies. That way you can factor out the two sources of effort: > (a) eliminating compiler dependencies, and (b) porting from compiler > independent Ada-83 to compiler independent Ada-95. In practice nearly all porting problems will be due to one of the following: o Implementation dependencies in the original code o Rep clauses in the original code treated differently o Bugs in the original code o Bugs in the original compiler o Bugs in the new compiler Very few will be due to Ada-83 to Ada-95 changes. In Michael's case, it looks like just ONE of his problems (the wide character case) may be a geniune Ada 95 problem. He identifies several others as being Ada 83 to Ada 95 issues, but is confused in all these cases between language changes and implementation dependencies. > 2. When you see program_error, immediately suspect that you have to > call something from outside the package that you are now calling > from the bottom of the package during elaboration time. I would just say "access before elaboration". Such cases are always due to incorrect coding in the original program, but such errors are common. I am not sure what "bottom of the package" means, but the cases that can cause program error are well defined in the RM. > 3. Wherever possible put pragma pure, pragma preelaborate, pragme > elaborate_body in your visible parts. Where needed, put pragma > elaborate in your package bodies. This is not porting advice, but really programming advice (write code in a correct manner). In particular, missing pragma Elaborate's are instances of bugs in the original code. > 4. Before even running a test, convert all roundings and truncations > to Ada-95 rounding and truncation attributes. Definitely NOT required in the usual case unless again the original code or the original compiler has bugs in it. > 5. Although there is a very large space advantage for not using the > -g attribute on your compile and bind, the run time penalty appears > insignificant. Using -g does not just cause an insignificant run time penalty it causes ABSOLUTELY ZERO penalty. A fundamental point of the design of the debugging capability in GNAT is that it is entirely non-intrusive. It does not change one bit of the executable. There is also zero space penalty, except in the space required to store the executable on disk. A constant error that people make is to assume that executable program size is proportional to the size of the executable file. This is not so, precisely because the executable file contains debugging information that is loaded ONLY if you run GDB or some other debugger that accesses the information. > 6. Optimization levels O2, O3, and gnatn may not gain as much execution > time as level O1 gained. That's often true. Of course it is clear that the program that Michael is porting does not do much arithmetic, that's clear rom the next point, so you cannot necessarily assume this will be true for you. In particular, -gnatn may result in HUGE gains for some programs. How much gain -gnatn will generate is of course dependent on how aggressively pragma Inline has been used. You might also try using -gnatN if you are on version 3.09, which forces all possible inlining but generates LOTS of dependencies. > 7. Although the documentation states that overflow checking (the -gnato > option) generates a lot of code, in this example there was not much of > an execution time penalty, so for safety, you can probably always compile > with both -g and -gnato. The conclusion here is entirely unwarranted. Just because one small program shows this behavior does not mean you can extend this to other programs. A factor of 2 slowdown with -gnato is not unusual for programs doing heavy arithmetic, and it is easy to construct examples of bigger slowdowns. Of course if these inefficiencies are not a problem, then it is certainly a good idea to use -gnato, and you certainly want to use -gnato while porting to smoke out elaboration order errors in the original code. > 8. When gnatmake says you are up to date and you know you just changed > the source code (possibly to an earlier dated source code, in order to > switch back ends), just delete the appropriate ALI files and reissue > the gnatmake. If this is accurately reported, it is a bug in gnatmake, and certainly with the current version, we know of no such serious bugs. If you find this happening, it may be because you have things set up wrong, or it may be a bug. If you suspect the latter, try to narrow it down and report it. Certainly we, and our customers, use gnatmake extensively, and no one has ever reported this bug. > 9. Learn the b, run, and bt commands of gdb and use them extensively. Gnat > out of the box without gdb does not print stack traces when you get > an unhandled exception, such as a constraint_error. That is certainly one bit of unambiguously good advice here. Actually gdb has a very powerful command set and can do all sorts of things. It is worth reading the GDB manual to find out all it can do. > 10. When you get messages like variable has not been initialized, take it > with a grain of salt, because gnat does not always see initializations across > generics, separately compiler packages, and some other forms of aliasing. > However, investigate those occurrences, as well as all other warning > messages. When the warning is accurate, fix the problem. Happy porting. If there are cases where this warning is not noticing initializations across generics or separate compiler packages, that is a bug. We are aware of no such bugs, and indeed it would be surprising if there are any such cases. However, if you find one, then please surprise us by sending in the appropriate bug report. If you are doing nasty aliasing, e.g. using overlaying, then indeed you can fool this warning, but these are cases where you also fool the optimizer potentially, so be very careful. Several of the warnings in GNAT are not always "correct". For example, if there is a procedure with no parameters that contains a recursive call to itself, then you get a warning about potential infinite recursion. Someone complained about this the other day, and I was considering taking it out, when the following day, it rescued me from what would have been a tricky bug to find, so I kept it in. Remember that you can always suppress a particular annoying warning by using -gnatws on the unit, or putting pragma Warnings (Off) in the unit. If you really want to narrow the suppress down to a single statement, put Warnings (Off) before and Warnings (On) after. HOWEVER, I do not know of a single instance where the warning about a variable never being assigned a value has been wrong. I am not exactly sure what warning Michael is referring to. As in the case of confusing error messages in general, if you get a warning that you think is definitely wrong, report it as a bug. We may not be able to "fix" it, but we may, you never know. Robert Dewar Ada Core Technologies.