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-Thread: 103376,b8b8a54001adc4d2 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news3.google.com!news.glorb.com!border1.nntp.dca.giganews.com!nntp.giganews.com!local1.nntp.dca.giganews.com!nntp.megapath.net!news.megapath.net.POSTED!not-for-mail NNTP-Posting-Date: Tue, 11 Jan 2005 14:22:01 -0600 From: "Randy Brukardt" Newsgroups: comp.lang.ada References: <1104516913.718856.94090@z14g2000cwz.googlegroups.com> <1104544963.930877.75170@c13g2000cwb.googlegroups.com> <1104595073.731663.180100@c13g2000cwb.googlegroups.com> Subject: Re: Possible Ada deficiency? Date: Tue, 11 Jan 2005 14:23:37 -0600 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Message-ID: <_ZCdnTiNfpH0qHncRVn-2Q@megapath.net> NNTP-Posting-Host: 64.32.209.38 X-Trace: sv3-hvFnxuttTvgLueoTyAltl4tSqZ0qto8/70WIYjLrLhtw2KmZAlZD/WCILAM1bejqjJImM7r5131SFHO!Or2kFeI2VOeIJWIjYv/zBTJih3nGN+Zn4f0GeehUBWnICMs4iVtgmH3xbdHlHjPsfB/M2eDtVGwm X-Complaints-To: abuse@megapath.net X-DMCA-Complaints-To: abuse@megapath.net X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.3.22 Xref: g2news1.google.com comp.lang.ada:7651 Date: 2005-01-11T14:23:37-06:00 List-Id: "Robert A Duff" wrote in message news:wccbrbx3qbp.fsf@shell01.TheWorld.com... > "Randy Brukardt" writes: ... > >... inline is a hint and the > > dependencies need not (and should not) be used. Do any inlining/macro > > expansion at link-time. > > I don't see link-time as an improvement. Whether you do this work at > compile time or link time, it still costs in terms of rebuild time. > And either way, you have to redo the work when the body changes. Sure, but if the extra rebuild time isn't significant, who cares? > >...Certainly I wasn't the only one who thought that was > > the intent. > > But you're the only one who implemented it that way! I certainly wasn't the only one to share generics by default. I'm pretty sure the old Rational compiler worked the same way. I'm the only one bull-headed enough to maintain that approach in the face of Ada 95, though. :-) > >...Machines of the era weren't really powerful enough to implement > > that intent, thus the hacks of the generic dependency and the inline > > dependency were allowed. > > > > Of course, Ada 95 came along and changed that intent. > > I don't understand that. Maybe I don't understand what you mean by > "that intent". Which rules of Ada 95 are you talking about, here? There are many rules of Ada 95 that make sharing impractical (not impossible, just impractical). For instance, there was no reason in Ada 83 to make the size of generic formal types the same as the actual type. (Ada 95 requires that because of aliased objects.) Whereas, Ada 83 had just one (the previously mentioned parameter passing style), and there never has been a test written that could show the difference (such a test would be very dubious anyway). > >... Which is too bad, as > > machines now are powerful enough to implement the Ada 83 intent! > > I don't understand that, either. Are you saying that the run-time > overhead of the always-share model is now acceptable? No, I was thinking of the time/space requirements for building such a compiler "properly". We didn't really implement my design because our hosts didn't have enough memory to store the intermediate code for the entire program, and a disk-based solution would be way too slow. It would be practical on modern machines (other than that I can't predict the performance of the optimization pass, which would be critical to making the scheme work. We'd have to build it to see). Note that with the design that I had in mind, the run-time overhead of "always share" (as you put it) would be greatly reduced by partial evaluation and inlining optimizations -- done at link-time so that all of the instantiations and calls are known. Plus, pragma Inline could be used to reduce the overhead to nearly nil on critical stuff. The problem isn't the run-time overhead so much as it is supporting the optimizations necessary to mitigate it. Randy. > - Bob