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,1676be4fafed1dbb X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news1.google.com!newsfeed.stanford.edu!headwall.stanford.edu!HSNX.atgi.net!cyclone-sf.pbi.net!151.164.30.34!cyclone.swbell.net!bos-service1.raytheon.com!dfw-service2.ext.ray.com.POSTED!53ab2750!not-for-mail Message-ID: <416F1EA4.5080700@acm.org> From: Arthur Schwarz User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Semantics of Inline vs non-Inline References: <35f054ea.0410140733.5f250e6f@posting.google.com> <1427975.D57Qmkl0pE@linux1.krischik.com> In-Reply-To: <1427975.D57Qmkl0pE@linux1.krischik.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 14 Oct 2004 17:49:40 -0700 NNTP-Posting-Host: 192.199.68.158 X-Complaints-To: news@ext.ray.com X-Trace: dfw-service2.ext.ray.com 1097801381 192.199.68.158 (Thu, 14 Oct 2004 19:49:41 CDT) NNTP-Posting-Date: Thu, 14 Oct 2004 19:49:41 CDT Organization: Raytheon Company Xref: g2news1.google.com comp.lang.ada:5227 Date: 2004-10-14T17:49:40-07:00 List-Id: Martin Krischik wrote: > skidmarks wrote: > > 1st: only aliased data is guaranteed to have an 'Address. Even non inline > functions may use a register for certain data. The question still remains concerning the semantics of inline vs non-inline. You are saying that the interpretation of inline depends on the compiler generated code, not focusing on the remapped address at the moment. If this is true, then it would seem that the application should not be able to use inline at all since the application (writer) can not control the compiler generated code and the generated code effects the execution, not the semantics implicit in the subprogram. Going back to the 'Address issue, it is my (unsubstantiated) belief that if the semantics are to be the same for inline and non-inline code, then it should be the compilers responsibility to ensure that argument passage is guaranteed to be correct. Otherwise any argument passed to a subprogram becomes suspect as being able to generate a fault at runtime. Looking at this issue as a an optimization concern then (to me) it appears that generating the same code required for a CALL for an inline, but without the CALL and RETURN instructions, would allow the semantics to be inviolate and the optimizer to optimize away the unnecessary generated code. This is presented as an oversimplified model, admitedly. What seems to be done in this case is to do 'pre-optimization' by not pretending that we are interfacing with a subprogram, but by just doing the Ada equivalent of macro text substitution, and then not detecting potential runtime errors. My objection is that the non-inlined code, with all it's conceptual and design flaws, works as expected. The inline code fails at run- time without a diagnostic message at compile time. My expectation was that the results of inline execution and non-inline execution should have been the same. And so I am confused. The question is still whether Ada requires that the result of execution of the inline and non-inline code to be the same, and if not the same, what variances are permitted. Another respondent on this newsgroupt said that the the compiler can substitute one type of 'number' for another, but he did not say whether the result of this substitution would yield the same result (or the Ada rationale that allows this substitution to occur). Any ideas or am I way off-base? Thanks for your reply. All typing errors (here) are do to haste and not necessarily grammatical deficiency. I am stealing time to answer (quickly) and have not edited this document. Sigh. Ever the slave to time, never it's master. thanks art > > With Regards > > Martin >