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

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

[Michael F Brenner]

This is a report on the conversion of a 50,000 line Ada-83 software
application to Ada-95. Included are a list of the work that had to
be done, the amount of time it took, and the timing of the optimizations.
The computer program, called tsg, manipulates a large number of
integers and small character strings (24 characters at the most).

Some of the source code is on the PAL, some of it has been posted to this
group, and all of it is Free.

It was originally written on a Janus compiler, but rapidly exceeded
the maximum size of the symbol table and object code for Janus 16 bit.
It works on the following Ada-83: Meridian (pc), Alsys (pc), Dec (vaxen),
and Sun/Verdix (sparc). It was ported to Ada-95 (it now works on gnat),
but remaining backwards compatible to Ada-83. Part of this compatibility
is done by selecting different package bodies for the same package, 
because this is how tsg maintains compatiblity amongst the Ada-83
compilers.

The work that had to be done was the following:

(1) A generic package had to be duplicated for unsigned (modular) numbers.

(2) The package body for bit manipulation routines had to use PACKAGE
INTERFACES (the bit packing bugs in gnat will soon be or already
have been fixed depending on which release you have, so the old
bit code will work again starting at that release of gnat). Now there
is nothing wrong with using package INTERFACES, except that it does not
exist in Ada-83. And during porting it would be preferred to do this
as a second optimizing pass rather than in the initial porting pass.

(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.

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

(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).

(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.

(7) Operating system interface functions had to be downloaded from the
Net, because, for example, gnat os_lib does not have the same functions 
in dos and unix, for example, get_first and get_next directory. Command 
line had to be written in assembly code because neither Ada-95 (for 
example ADA.COMMAND_LINE) nor gnat libraries give you access to the dos 
or unix command line. Rather they give you an array of arguments which
are not constructed the same in dos and unix. Ada-95 does not come out
of the box with a method of deriving the original command line from the args.

(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. Again this
brings up the suggestion of passing packages to generic packages, so we
can manage multiple (selectable) package bodies WITHIN the Ada 2005 language.

(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.

(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. GDB was used
to identify each program_error, and those regression tests were made
visible and called externally to the package. This solved the problem.
The ones giving the program_error were the ones elaborated between
the visible part and body of a different package. In some cases, 
we cold still call the regression test in the package body by identifying
everything it called as either pragma pure, pragma preelaborate, or
pragme elaborate_body. Pragma elaborate_all did not help, because it
gave the message cannot elaborate package X before itself. 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.

(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.

(12) Temporarilly (because of an early bug in gnat since fixed)
a procedure had to be written to get and set the elements of a packed 
array of bytes. This temporary package is now gone and ordinary 
array manipulation of packed arrays with greater than 64K bytes now
works. 

(13) Major changes had to be made in the line of code that reopened an
output file for input, to accomodate stream_io. 

(14) Our methods of getting an immediate key did not work in Ada-95, and 
neither did get_immediate. We downloaded some assembly code that does the
job from the Net. It is strongly recommended that the basic operations
of getting key strokes (is_available and get_immediate) be semantically
defined in Ada 2005 so that it works correctly whenever a keyboard is
supported. Having a get_immediate, but having it wait for the user to
press a stroke is worse than not having it, because it prevents you 
from estimating that you will need to program it. 


TIME IT TOOK TO PORT

All of the above was done on one Sunday (about 4 hours on my part
and about 4 hours on the part of the person who downloaded the get_first
directory code). Because I knew you would ask: I counted the number of
semicolons in the code, using the most abused unix sequence ever invented:
    command cat *.ad? | grep - c \;
This gave me a value of 51743 semicolons. To count the number of units,
(which equals the number of files under gnat), I used the command 
    ls -1 *.ad? > \tmp\tmp.tmp; vi \tmp\tmp.tmp
This displayed that there were 766 units and 12541 characters in the code.
41 units were changed (including 2 brand new packages which were 4 units).
One of those 41 units, the one providing get_next_directory under unix, took
half of the porting time. The size of the unit providing get_next was 7 lines
visible part, 131 lines body, and its works by generating a unix ls command,
spawning it, then using text_io to read the directory listing back in, 
which is horrible, but it works. The size of the other new package was
199 semicolons in a visible part and no body (although it instantiated a body
consisting of 1872 semicolons). 636 lines of code were changed, many using
global search and replace commands in a text editor; this was counted by 
adding up the total number of lines produced by running DIFF like this:
    diff -e x.adb x.bak

Actually more than 636 lines were changed: some lines were changed
several times, and some were changed and then changed back after learning
Ada-95 and gnat better. However, 636 insertions and deletions would be needed
to take the old baseline into the new baseline. The code was originally
an object oriented (bottom-up) design with one package per data structure 
which made the porting go much faster than, say, a traditional, monolithic 
top-down program. Other things that saved time in the porting: Ada-95 is
very close to being a superset of Ada-83, the code used no pointers and 
almost no unchecked_conversions, the machine dependencies were strongly
isolated (keyboard, command line, append files). I think the most 
important thing that made the port go fast was that it had already been
ported to several Ada-83 compilers, so it was VERY compiler independent.


SPEED OF EXECUTION

The following charts show the execution times on Unix Sparc Ada-83,
Unix Sparc gnat 3.08, DOS Alsys Ada-83, and DOS gnat 3.07. All of these
compilers have recently been upgraded to later versions, so results 
should improve if you repeat these timings today. The 90MHz Pentium had
64 megabytes RAM. The 75 MHz Sparc-20 had 

The program runs in two modes called regular and speedy. Regular mode
has the inner simulation loop coded in an easily readable, easily 
testable manner. Speedy mode is hand optimized by lifting certain
operations out of the inner loops, which would require domain knowledge
for a compiler to remove. 

In addition, the internal heap storage had a debugging_heap flag. When
this was turned on, the program took a lot longer because each reference
to a data object was first looked up on the buddy list. After it was 
found, it was looked up linearly across the entire heap to verify that
the buddy list software was working. This made it take longer. 
Multiple runs on both the Pentium and the Sparc varied by up to 2 seconds.


THE 75 MHz SPARC 20                REGULAR          SPEEDY

a. With debugging heap
flag turned on.                5 min 32 sec     3 min 32 sec
gnatmake -f -g -gnato

b. With debugging flag
turned off.
gnatmake -f -g -gnato          4 min 18 sec     1 min 13 sec

c. gnatmake -f -g -gnato -O1   2 min 24 sec     0 min 37 sec

d. gnatmake -f -g -gnato -O2   2 min 07 sec     0 min 34 sec

e. gnatmake -f -g -gnato -O3   1 min 58 sec     0 min 33 sec

f. gnatmake -f -g -O3          1 min 56 sec     0 min 31 sec

g. gnatmake -f -O3             1 min 57 sec     0 min 31 sec

h. gnatmake -f -O3 -gnatn      1 min 54 sec     0 min 33 sec

i. Sparc Ada-83                1 min 44 sec     0 min 51 sec


THE 90 MHz PENTIUM                 REGULAR          SPEEDY

a. With debugging heap
flag turned on.                2 min 54 sec     2 min 01 sec
gnatmake -f -g -gnato

b. With debugging flag
turned off.
gnatmake -f -g -gnato          2 min 43 sec     0 min 43 sec

c. gnatmake -f -g -gnato -O1   1 min 21 sec     0 min 23 sec

d. gnatmake -f -g -gnato -O2   1 min 07 sec     0 min 23 sec

e. gnatmake -f -g -gnato -O3   1 min 58 sec     0 min 22 sec

f. gnatmake -f -g -O3          1 min 50 sec     0 min 23 sec

g. gnatmake -f -O3             1 min 57 sec     0 min 21 sec

h. gnatmake -f -O3 -gnatn      1 min 54 sec     0 min 21 sec

i. Alsys-83                    1 min 18 sec     0 min 56 sec


CONCLUSIONS:

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.

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.

3. Wherever possible put pragma pure, pragma preelaborate, pragme
elaborate_body in your visible parts. Where needed, put pragma
elaborate in your package bodies.

4. Before even running a test, convert all roundings and truncations
to Ada-95 rounding and truncation attributes.

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. 

6. Optimization levels O2, O3, and gnatn may not gain as much execution 
time as level O1 gained.

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.

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.

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. 

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.  

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

[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.

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

[Larry Kilgallen]

In article <dewar.856407400@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) writes:
> Some comments on Michael's porting experience
> 
> (my comments are marked by -->)

> (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.

Is this problem totally impossible in non-DOS environments, or just less
likely (for those of us who think adding pragmas changes source :-)  ?

Larry Kilgallen

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

[Robert Dewar]

Larry asks

<<Is this problem totally impossible in non-DOS environments, or just less
likely (for those of us who think adding pragmas changes source :-)  ?>>

This will happen only if for some reason you need to keep file names
short (DOS is not the only system with limited file name length, there
are restrictions in MacOS, and VMS for example).

As for adding pragmas changing the source, that seems a bit tenuous, the
source files involved are not touched at all. The gnat.adc file of
configuration pragmas should be thought of as being more like default
compiler switches, rather than part of the source (or perhaps you think
compielr switches are also changes to the source???)

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

[Keith Thompson]

In <dewar.856407400@merv> dewar@merv.cs.nyu.edu (Robert Dewar) writes:
> Some comments on Michael's porting experience
[...]
> (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.

This is possible according to the Ada language definition, but it
seems unlikely to happen in real life.  Typically, Ada floating-point
comparisons are implemented simply by generating the appropriate hardware
compare instructions.  These instructions don't know anything about
Ada's concept of model numbers, they just operate on the bits.

It's possible that one or both operands are NaNs (IEEE Not-a-Number),
special non-numeric floating-point values that can result from operations
like 0.0/0.0.  Try printing the values you're trying to compare.
Note that the compiler's runtime routines may or may not handle NaNs
(the language definition doesn't say much about them), so you may have
to do something like an Unchecked_Conversion to an integer type of the
same size to figure out exactly what the values are.  The SPARC processor
manual specifies the layout of the floating-point types, including the
representation of NaN, Infinity, signed zero, denorms, and so forth.

It may also be that the comparison is being done with values in registers
that are stored with different precision than the values in memory,
though I'm not sure how that would lead to the results you describe.

I'd be interested in seeing a small example of this.

-- 
Keith Thompson (The_Other_Keith) kst@sd.aonix.com <http://www.aonix.com> <*>
TeleSo^H^H^H^H^H^H Alsy^H^H^H^H Thomson Softw^H^H^H^H^H^H^H^H^H^H^H^H^H Aonix
10251 Vista Sorrento Parkway, Suite 300, San Diego, CA, USA, 92121-2706
Antimatter is not a condiment.

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

[Robert Dewar]

Keith says

<<This is possible according to the Ada language definition, but it
seems unlikely to happen in real life.  Typically, Ada floating-point
comparisons are implemented simply by generating the appropriate hardware
compare instructions.  These instructions don't know anything about
Ada's concept of model numbers, they just operate on the bits.>>

wishful thinking I am afraid. In practice funny things can happen. Consider
the following:

    if a + b > 3.45 then ...

    if a + b = 3.45 then ...

it can easily happen that both of these are true, due to extra temporary
precision in intermediate results. FOr example, consider you are on an
x86 where all registers are 80 bits, and the initial comparison computes
a+b into an 80 bit register and compares it. But the second comaprison
uses a saved value of a+b, which was unfortunately stored in memory in
a 64-bit temporary.

This sort of thing happens in real life all the time on such machines!

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

[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.

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

[Mats Weber]

>     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.

or bugs in the language definition ? :-) :-) :-)

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

[Robert Dewar]

Mats said

<<>     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.

or bugs in the language definition ? :-) :-) :-)>>

I see lots of smileys here, but I still do not konw what you are getting
at. Do you think there are ways in which this could have been handled
better, that would have been practical?

Elaboration order (was: Effort to Port TSG to Ada-95 and How Fast it Ran in Gnat)

[Mats Weber]

> <<>     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.
> 
> or bugs in the language definition ? :-) :-) :-)>>
> 
> I see lots of smileys here, but I still do not konw what you are getting
> at. Do you think there are ways in which this could have been handled
> better, that would have been practical?

I wrote an article on the subject that was published in Ada Letters a
few years ago (I don't remember which issue, but I can send a copy to
anyone who is interested).

The article is also part of my thesis (sections 2.7 and 4.5) which is
accessible at
http://lglwww.epfl.ch/Team/MW/Ada-Extensions/Ada-Extensions.html

Essentially, I think it solves all *reasonable* occurences of
Program_Error being raised at elaboration time because some subprogram
or generic body has not been elaborated.

Of course, you may or may not agree with my view of what is a
"reasonable" elaboration order dependence, but I think that
incorporating my solution into Ada 95 would have solved most cases in
practice.