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,3cd797aa3bdcb07b X-Google-Attributes: gid103376,public From: Martin Dowie Subject: Re: performance of Generic and strings Date: 1999/08/13 Message-ID: <37B4335E.7A69258B@dowie-cs.demon.co.uk> X-Deja-AN: 512280270 Content-Transfer-Encoding: 7bit X-NNTP-Posting-Host: dowie-cs.demon.co.uk:193.237.34.207 References: <37B18AB6.BBAEF44A@pwfl.com> <7osak8$gph$1@nnrp1.deja.com> <37B1B634.543D131D@pwfl.com> <7ovq7d$km$1@nnrp1.deja.com> X-Accept-Language: en Content-Type: text/plain; charset=us-ascii X-Complaints-To: abuse@demon.net X-Trace: news.demon.co.uk 934556459 nnrp-04:7044 NO-IDENT dowie-cs.demon.co.uk:193.237.34.207 MIME-Version: 1.0 Newsgroups: comp.lang.ada Date: 1999-08-13T00:00:00+00:00 List-Id: Rational can do either and you can specify which either via switches (environment variables) or a (non-standard) pragma. the default set is for macro expansions. and they advise that trying to use shared bodies may result in inefficient code. Robert Dewar wrote: > In article <37B1B634.543D131D@pwfl.com>, > e108678@pwflcom wrote: > > I have also been informed by > > other experts in the Ada compilation field that there are > certain > > language issues involved with the macro expansion technique > which make > > the profile technique more attractive. (I won't name names, > not wishing > > to draw anyone unwillingly into the fray, but feel free to > leap to my > > defense here. :-) > > You have been informed exactly wrong (or misunderstood :-) > It is FAR FAR easier to do macro expansion, and indeed the > design of Ada 95 pretty much assumes macro expansion for > specs. Bodies can be shared, but general sharing of bodies > is VERY VERY tricky, ask Randy Burkhardt :-) > > > As to which is more commonly used? Not being a compiler vendor > myself, > > I'll defer to those who make it their business to know the > market. > > GNAT certainly uses macro expansion, so does Intermetrics (and > hence Greenhills, Aonix, SHARC and any other Ada 95 compiler > using the Intermetrics front end. > > Rational used to do code sharing in Ada 83, but I am pretty > sure the new Rational technology uses macro expansion. > > I am not aware of any validated Ada 95 compiler that does NOT > do macro expansion (counter examples welcome to be posted :-) > > > However, between the two, I think I'd rather have > instantiation done > > with some sort of profile information rather than expansion. > While > > normally, I'd come down on the side of speed, in this > instance, I'd > > prefer the space savings as long as the time penalty was > minimal. > > The time penalty is not at all minimual. Many simple things > have to be done by passing thunks. In practice the best you > can do is to share some simple cases of generics, but then > you might fall afoul of the Digital patent. Full general > sharing imposes a very significant penalty. For example, > what do you do with a digits formal? Do everything in > double precision? Well, apart from the obvious time penalty, > that's not quite right for special cases like > Unchecked_Conversion and 'Machine. So you have to pass > thunks for these operations. Consider integer, and things > get worse. To use 64-bits for all integer operations is > far too expensive on some machines. > > Dan Eilers (Irvine) has suggested significant additions in > the language to make more sharing of generics feasible, since > he is interested in doing sharing, but considers the language > in its current form simply too hostile to efficient sharing > (i.e. the time penalty is just too great). > > Note other annoying areas are exceptions, where exceptions must > be unique in different instantiations, and obscure programs can > tell the difference. There are many many other gotcha's in > implementing general shared generics. > > Note that shared generics will cause a space *penalty* if > a generic is instantiated only once, a common occurrence in > many programs. > > Note also that the space penalty is quite small if a generic is > designed so that most common code is in a non-generic helper > unit (see implementation of Integer_IO in GNAT for an example > of this approach, or Direct_IO). > > > It > > also greatly reduces verification problems, which is a > > tremendous concern around here. > > I am not at all sure that it reduces verification problems. > Obviously if you are doing only one instantiation, it greatly > increases the problems, because the code is so much more > complex, and will rely on a lot of indirect subprogram calls, > for the thunks, always a big worry for verification environments > (some verification protocols simply prohibit indirect calls > completely). > > For macro instantiation, you do have to repeat the verification > for each instance, but the work to be done is far easier, > because you do the verification only for the particular instance > of the actuals, instead of having to verify the generic for all > possible instantiations. > > Indeed in the HRG discussions, some felt that generics could > ONLY be considered verifiable if instances were NOT shared. > > We decided early on in GNAT to provide only the macro > substitution approach. There is in fact nothing in the GNAT > technology that makes it hard to do generic code sharing. It > is neither easier nor harder in GNAT than it would be in any > other environment. We had anticipated concerns about this > approach, but so far it has not been a major issue. > > I will say that in general we see people being far more > concerned about space than time, so I can easily see that > there might be environments in which the overhead of sharing > would be a good trade off for the saved space. However, I > suspect that sharing of generic bodies is hard enough in Ada 95 > than it may never get done in the GNAT environment (at least by > ACT), we have lots of other things to do before that. > > I must say I am very surprised that anyone in the Ada compiler > community would claim it is easier to do sharing than macro > expansion, given that the difficulties of generic sharing are > positively notorious :-) > > Robert Dewar > Ada Core Technologies > > Sent via Deja.com http://www.deja.com/ > Share what you know. Learn what you don't.