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,38fc011071df5a27 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-06-03 11:48:40 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed.stueberl.de!newspeer1-gui.server.ntli.net!ntli.net!news-hub.cableinet.net!blueyonder!internal-news-hub.cableinet.net!news-binary.blueyonder.co.uk.POSTED!53ab2750!not-for-mail User-Agent: Microsoft-Entourage/10.1.1.2418 Subject: Re: Ideas for Ada 200X From: Bill Findlay Newsgroups: comp.lang.ada Message-ID: References: <6a90b886.0305262344.1d558079@posting.google.com> <3ED41344.7090105@spam.com> <3ED46D81.FF62C34F@0.0> <3ED46E07.4340CABC@0.0> <3ED4F3FD.A0EF7079@alfred-hilscher.de> <6vWcnTWjF83bD0qjXTWcpA@gbronline.com> Mime-version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Date: Tue, 03 Jun 2003 19:47:34 +0100 NNTP-Posting-Host: 80.195.75.181 X-Complaints-To: abuse@blueyonder.co.uk X-Trace: news-binary.blueyonder.co.uk 1054666119 80.195.75.181 (Tue, 03 Jun 2003 18:48:39 GMT) NNTP-Posting-Date: Tue, 03 Jun 2003 18:48:39 GMT Organization: blueyonder (post doesn't reflect views of blueyonder) Xref: archiver1.google.com comp.lang.ada:38537 Date: 2003-06-03T19:47:34+01:00 List-Id: On 3/6/03 17:44, in article wcc4r37kt5s.fsf@shell01.TheWorld.com, "Robert A Duff" wrote: > Bill Findlay writes: >> As I see it there are several arguments in favour of the 'idem' proposal: >> 1. It lets the programmer indicate that the occurrences of the LHS in the >> RHS are *necessarily* the same, and not contingently so, which makes the >> code more self-documenting. ... >> 5. It requires the compiler to evaluate the lvalue of the LHS once and reuse >> that lvalue as often as needed to evaluate the RHS. This has three potential >> benefits: shorter code, faster execution, and once-only invocation of any >> side effects. >> 6. It might make it somewhat easier for the compiler to generate >> update-in-place object code, where the target architecture allows that and >> where it offers a performance advantage. >> ... > Number 6 applies only if there are non-inlined calls involved. > They presumably don't normally have side effects (because that > would usually be wrong), but the compiler doesn't *know* that. > That is, currently the compiler can avoid evaluating X twice in > "X := X + 1;" only if "X" contains no out-of-line function calls. Do volatile variables not come into play in defining eliminable CSEs (probably not the right language-lawyer language, but YKWIM)? > Number 5 doesn't say anything that 1 and 6 don't say. I was going to quibble with that, saying that 5 requires an optimization that is only allowed at the moment, but I see that is covered by your take on "necessarily" in point 1. How would you see the semantics being explicated? The implicit access all method, or the implicit in out parameter method, or something else? -- Bill-Findlay chez blue-yonder.co.uk ("-" => "")