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=unavailable autolearn_force=no version=3.4.4 From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Ada202X: Easy to use "UML private"-like components Date: Tue, 25 Jun 2013 14:37:48 -0500 Organization: Jacob Sparre Andersen Research & Innovation Message-ID: References: <69246de0-4b33-4d47-b5be-a45e8c911fb0@googlegroups.com> <9qrbs8l828t3pvgves504a8fm7o1c7tcpj@4ax.com> <91qcs81k6am9l3u3n19lj0b072lc48td69@4ax.com> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: loke.gir.dk 1372189073 23309 69.95.181.76 (25 Jun 2013 19:37:53 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Tue, 25 Jun 2013 19:37:53 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Path: border1.nntp.dca3.giganews.com!border2.nntp.dca3.giganews.com!border4.nntp.dca.giganews.com!border2.nntp.dca.giganews.com!nntp.giganews.com!goblin3!goblin1!goblin.stu.neva.ru!feed.ac-versailles.fr!news.ecp.fr!news.jacob-sparre.dk!loke.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail X-Original-Bytes: 4348 Xref: number.nntp.dca.giganews.com comp.lang.ada:182084 Date: 2013-06-25T14:37:48-05:00 List-Id: "Robert A Duff" wrote in message news:wcctxknt2r7.fsf@shell01.TheWorld.com... > "Randy Brukardt" writes: ... >> Janus/Ada doesn't do inlining at all, ... > > Well, there goes (run-time) efficiency. Seriously, I don't see how > "don't do inlining" is a reasonable implementation of inlining. It's unclear to me that inlining makes enough difference for the implementation earthquake that it would have represented in Janus/Ada (several man-years of work). Since Janus/Ada compiles statements directly from their syntax, the largest program structure that it can store is an expression tree (and that was a later change, necessitated by the requirements of Ada resolution - the original design was purely syntax-driven). That would allow inlining of expression functions (and functions that are similar to expression functions), but little larger. (One could imagine converting if statements into if expressions to allow a bit more inlining.) >>...other than of things visible in >> specifications (expression functions make a significant expansion of what >> can be inlined -- one of the reasons the idea was invented in the first >> place, many years ago). If it ever does do inlining of subprograms, it >> would >> do it at bind-time, (and mostly automatically). > > "mostly automatically" is good. > > But I don't see how bind time (i.e. link time) helps. It's a reasonable > approach, but it takes just as long to generate code at link time as it > does at compile time, for the same generated code. If you modify the > procedure body being inlined, you have to regenerate code at all call > sites, either way. Doing this at bind-time allows inlining stuff that neither the user nor the compiler really know might be inlined, and it also allows partial evaluation of calls based on what is actually present in the program (think about the second parameter to New_Line -- it's hardly ever used; code shared generics have a similar parameter for sharing information, of course). (It also allows other cross-procedural optimizations.) Final code generation obviously has to occur after those optimizations, so it would always be done at bind-time in that scenario. So there wouldn't be any incremental cost to inlining (other than the cost of actually doing it). This wasn't a practical implementation in 1995 (which is why we didn't do it then), but it was always the intended end-game for Janus/Ada. (That code generation can be parallelized, and much of the cost of binding disappears if the code generation is delayed, so on a modern multi-core I wouldn't expect the binding time to grow that much.) Anyway, if I spent less time writing about this implementation and more time creating it, we could see how well it works. ;-) Randy.