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.3 required=5.0 tests=BAYES_00,INVALID_MSGID 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: michael@ifr.luftfahrt.uni-stuttgart.de Subject: Re: seperate keyword and seperate compilation with Gnat? Date: 1996/07/08 Message-ID: <4rrdn0$10mk@info4.rus.uni-stuttgart.de>#1/1 X-Deja-AN: 167213970 references: <31D95D93.28D8D15B@jinx.sckans.edu> <31DA7327.6CE2@epi.syr.lmco.com> organization: Comp.Center (RUS), U of Stuttgart, FRG newsgroups: comp.lang.ada Date: 1996-07-08T00:00:00+00:00 List-Id: dewar@cs.nyu.edu (Robert Dewar) wrote: > Regarding the issue of subunits and GNAT. > [...] > > 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). > So, you don't consider me a customer anymore? :-) We talked about precisely this issue at the GNAT workshop in Frankfurt last year. The fact that GNAT does not compile subunits into separate object files caused us some problems when we switched from Verdix to GNAT. We have now restructured our code so this is not a big issue anymore, but in order to save compilation time during developement it would still be helpfull to have this feature. All of our examples are of type 2 and if a separate code generation could be achieved easily it would be nice to have but there are certainly more important problems to be solved (e.g. a more efficent handling of unconstrained arrays). Michael -- ------------------------------------------------------------------------ --Dipl.-Ing. Michael Paus (Member: Team Ada) --University of Stuttgart, Inst. of Flight Mechanics and Flight Control --Forststrasse 86, 70176 Stuttgart, Germany --Phone: (+49) 711-121-1434 FAX: (+49) 711-634856 --Email: Michael.Paus@ifr.luftfahrt.uni-stuttgart.de (NeXT-Mail welcome)