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.7 required=5.0 tests=BAYES_00,INVALID_DATE, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!samsung!aplcen!haven!vrdxhq!edm From: edm@vrdxhq.verdix.com (Ed Matthews) Newsgroups: comp.lang.ada Subject: Re: Use of "is separate" and compilatio Message-ID: <23960@vrdxhq.verdix.com> Date: 28 Nov 89 17:40:58 GMT References: <20600021@inmet> Reply-To: edm@vrdxhq.UUCP (Ed Matthews) Organization: Verdix Corporation HQ List-Id: I pretty much agree with Tucker. I used to really like separate subunits, but now that I have switched to the compiler development side of the world, it's easy to see that separate subunits is one of those issues that gives compiler and optimizer writers nightmares. In article <20600021@inmet> stt@inmet.inmet.com writes: >When making a change or trying to understand a particular >feature of the system, it is generally only necessary to >look at the single medium-size package which implements it. On the whole, Tuck makes some persuasive arguments, but I disagree here. This argument is an artifact of the editors of the past. With modern editor technology and windowing, the entirety of a package, whether it be one package of 2500 lines, or 25 subunits of 100 lines, can be easily viewed. Further, in editors with syntactic and semantic navigation, understanding a unit is equally easy no matter how the program is structured. >Furthermore, most of the candidates for low-level, small-chunk-of-code >reuse, are within a single package. I agree here -- reuse at the small-chunk-of-code level may be obscured by subunits. This is another another topic, but I wonder how much value small-chunk-of-code reuse represents on the reuse continuum. I do a lot of reuse at this level. >Thirdly, subunits cause havoc with sophisticated optimizers, >especially subunits within subprograms. When calling a separately-compiled >subunit the compiler must assume the worst: that the subunit >accesses and/or updates all objects it can see, meaning that >all local variables visible to the subunit must be stored back >into memory from registers before the call, and reloaded afterward. Furthermore, the compiler has to assume that the subunit may contain tasks and then it has to generate code to check for task termination etc. Two guidelines to think about when using separate subunits: 1. Separate subunits should be declared in package bodies, not in subprograms. 2. Nest subunits only one layer deep. A reasonable relaxation might allow separate package bodies inside separate package bodies. -- Ed Matthews edm@verdix.com Verdix Corporation Headquarters (703) 378-7600 Chantilly, Virginia