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

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

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.