Re: seperate keyword and seperate compilation with Gnat?

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

Regarding the issue of subunits and GNAT.

First, there are three reasons why we did things this way originally:

a) it greatly reduces complexity, since subunits are no longer a special
case, as anyone who has implemented an Ada compiler knows, subunits are
a nasty source of problems ("of course we know if a scope contains tasks
or not at compile time .... oops, no we don't -- subunits! darn!")

b) we are building on a backend that has no concept of separate compilation
of nested procedures, although luckily it did have the capability of nested
procedures (because this was an existing extension to GNU C). It certainly
would be possible to enhance the backend to have this capability, but it is
a major effort, and at the moment many other enhancements have priority over
this. Adding also to the decision to minimize work on this feature originally
was the fact that this was one of the features we had to implement on our
own time [in response to concerns from other vendors, the DoD support
specifically excluded support for certain features, including fixed-point
and subunits]. Luckily Ed and I both had sabbatical years to devote to the
project so we were able to implement these missing features without using
DoD resources, but still this did limit the resources that could be spent
on some of these features -- or perhaps more accurately, did help dictate
our allocation of resources in the initial project at NYU.

c) subunits are relatively less important in Ada 95, since many uses of
subunits (but certainly not all), are subsumed more conveniently by the
use of child units in Ada 95.

That being said, it certainly is true that in terms of performance (but
not in terms of conformance to the standard), it would be nice to have
"real" separate compilation of subunits.

We have looked into this issue recently, and here is one interesting
observation. There are two quite different types of subunits:

   1. Those which are ultimately nested within a procedure

   2. Those which are ultimately nested within a library level package

For example, if you have a package spec with a bunch of subprograms, and
then a package body, where the  bodies of the subprograms are stubs, this
would be type 2 subunits.

What we have realized is that it is very easy to compile type 2 subunits
separately, and does not require any major backend work (unlike the type 1
case).

So here is an interesting question for those who have these cases of big
subunit strucures, are your subunits type 1 or type 2? In other words,
would it help to specifically deal with the type 2 case?

Neither case has been high on our priority agenda since (a little 
surprisingly actually), it is not something any users have particularly
commented on (and they are certainly not hesitant to comment :-) I
guess this shows that large subunit trees are not that common although
there certainly are exceptions (the old Alsys technology Ada compiler
would certainly have been a type 1 exception for example).

One thing that is interesting is that if you *don't* modify any of the
sources in the subunit tree, but have to recompile anyway because of some
other dependency, then the GNAT approach results in much faster compilation
time, since in a case like this where the parent and hence the whole tree
must be recompiled, it compiles faster if compiled all at once. If you
look at the sources of the compiler, the parser is structured this way.
Actually the parser could perfectly well be restructured to use child
units (which were not available when it was originally written), but
we thought it useful to leave in a substantial use of subunits in the
compiler, so that this feature gets constantly tested.

It is of course true that if you have a big subunit case, you not only
have to worry about compilation time, but also memory usage, which can
indeed get large, although that's some what less of a worry these days
with disks getting so cheap.

Anyway, it would really be interesting to here if there are interesting
examples of large type 2 cases which would make it worth fixing at least
this subunit case to do "true" separate compilation.

A trend in the opposite direction is to consider doing more compilation
at link time anyway. The MIPS C compilers typically delayed register
allocation to link time, resulting in longer link times, but better code.
Note that it is definitely the case that the code generated by the current
GNAT approach is superior to what can be achieved when doing true separate
compilation, because you know much more at compile time. When you have true
separate compilation of nested procedures, you have to assume the worst
about them (in terms of task usage, finalization etc) when compiling the
outer unit.

Robert Dewar