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=-1.9 required=5.0 tests=BAYES_00 autolearn=ham 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: dewar@cs.nyu.edu (Robert Dewar) Subject: Re: seperate keyword and seperate compilation with Gnat? Date: 1996/07/03 Message-ID: X-Deja-AN: 164035196 references: <31D95D93.28D8D15B@jinx.sckans.edu> <31DA7327.6CE2@epi.syr.lmco.com> organization: Courant Institute of Mathematical Sciences newsgroups: comp.lang.ada Date: 1996-07-03T00:00:00+00:00 List-Id: 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