From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=BAYES_00,INVALID_MSGID, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,6a9844368dd0a842 X-Google-Attributes: gid103376,public From: Rob Kirkbride Subject: Re: seperate keyword and seperate compilation with Gnat? Date: 1996/07/03 Message-ID: #1/1 X-Deja-AN: 163511031 distribution: world x-nntp-posting-host: rk-comp.demon.co.uk references: <31D95D93.28D8D15B@jinx.sckans.edu> organization: Bedrock Corp. mime-version: 1.0 reply-to: Rob Kirkbride newsgroups: comp.lang.ada Date: 1996-07-03T00:00:00+00:00 List-Id: >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