Re: seperate keyword and seperate compilation with Gnat?

[Rob Kirkbride <rk-comp@rk-comp.demon.co.uk>]

>I have been waiting for Mr. Dewar or someone else from ACT to reply to
>your question. We have been using GNAT since version 2.06 and it has
>always treated subunits this way. (A "subunit" is a procedure, function,
>or package body that is separate from its enclosing package body. A
>subunit body is preceded by a "separate(package_name)" clause.)
>
>It appears that what GNAT in effect does is a #include of all subunit
>bodies. If you try to compile a subunit by itself, GNAT will compile it
>but not generate any object code for it. Likewise, if you compile a
>package body which has within it subunit declarations (i.e. "function X
>return Boolean is separate;") GNAT will only generate object code *if*
>it can compile all of the subunits. 
>
>Now, I suppose that GNAT's "#include" approach could be defended
>by an argument like "GNAT *compiles* the subunits and their enclosing
>bodies in accordance with the LRM, it just doesn't generate object code
>for them unless ..."  I think that GNAT could thus be said to obey the 
>*letter* of the LRM, but "#include'ing" subunits does not, IMHO, obey
>its *spirit*.
>
>I have worked on projects where a significant piece of a system's 
>functionality was encapsulated within one Ada package. Some of these
>packages had over 100 functions and procedures in them, and we made each
>of these a subunit. Why? So that making changes to one of these
>would not require recompilation of the entire package body and all 100+ 
>subunits. The design of GNAT removes this important benefit. If you
>can't change a subunit and the re-link and re-run your program without
>having to recompile the enclosing package and all of the other subunits
>as well, why bother to have subunits at all? With GNAT, you might as
>well not use subunits unless (as in our case) you are planning to later
>port your code to environment that provides *true* separate compilation
>(i.e. Rational/VADS).
>
>Regards,
>
>Mike

I did ask ACT about this and they said that it generates significantly
better code. I have personally found it compiles the packages much
faster presumably because it doesn't have to keep loading the body in
each time a new separate is compiled. However, it may be also be due to
just being a better compiler!

However, I have encountered two problems with it. 
1) The first point is the one you mentioned, I am also working on a
project that has packages with upto 400 separates (I didn't design it
fortunately!). Although I have found it can compile the package in about
a third of the time than with another compiler on the same platform this
can still be upto half an hour, which can be a bit irritating if like
you say you've just changed a separate.
2) The other problem is that it seems to use a heck of a lot of virtual
memory as it compiles, which starts to slow it down by greater amounts
as it begins to swap. Its one thing I was going to ask Robert Dewar
about whether separates really should make the memory requirements go up
so much, and if so why. I have units that want over a gigabyte of
virtual memory to compile whereas another compiler only takes 100M or
so.

I suppose I was surprised that they managed to wangle this feature in.

-- 
Rob Kirkbride
rob@rk-comp.demon.co.uk