Re: Elaboration in GNAT

[Mark Johnson <Mark_H_Johnson@Raytheon.com>]

Robert Dewar wrote:
> 
> Some things to remember here:
> 
> 1. The static elaboration model of GNAT is primarily intended for the
> development of new code.
Hmm. I guess I disagree with that statement. See reasons below.

> [snip]
> 3. If you are working with legacy code, it often makes no
> sense to try to use the static model of GNAT, and you should simply
> use -gnatE, and use the RM dynamic elaboration model. I am always
> surprised by people who
> are absolutely determined to beat legacy code into submission to the
> GNAT static model. Yes, of course this
> makes life easier in the future, but you have to be sure
> it is worth the work.

Yes and no. Two examples follow.

The first example follows Robert's suggestion to use -gnatE. To predict
performance of our new system, we got a copy of ACES (Ada Compiler
Evaluation System) and ran several hundred of the test programs through
GNAT on the several target systems. Since this was a study and not
intended to be run operationally, we did not spend the time trying to
find and fix all the problems with this software. The use of -gnatE was
a good way to make progress without a lot of effort.

The second example is our real application. We are nearing the end of
porting a couple million lines of code from Apex & VADS to GNAT. We
actually have a small script that takes the compiler output, recognizes
the "pragma Elaborate_All" messages, and makes those changes
automatically. NONE of our software has broken when this was done. It
was relatively painless and easy to perform. I expect many other well
designed systems fall into this category.

The use of the warning of the compiler and the script to make the
changes has given us confidence that our code is free from any big
issues with elaboration. It is not a "big deal" to make the change in
most cases. As Robert's message goes on to say - complicated elaboration
code is likely filled with bugs anyway. I am glad we don't have this
kind of problem to worry about. 

--
  --Mark