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!newshub.sdsu.edu!news.glorb.com!border1.nntp.dca.giganews.com!border2.nntp.dca.giganews.com!nntp.giganews.com!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 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> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: Date: Thu, 14 Oct 2004 13:05:47 -0700 NNTP-Posting-Host: 192.199.68.158 X-Complaints-To: news@ext.ray.com X-Trace: dfw-service2.ext.ray.com 1097784348 192.199.68.158 (Thu, 14 Oct 2004 15:05:48 CDT) NNTP-Posting-Date: Thu, 14 Oct 2004 15:05:48 CDT Organization: Raytheon Company Xref: g2news1.google.com comp.lang.ada:5224 Date: 2004-10-14T13:05:47-07:00 List-Id: Wojtek Narczynski wrote: > Hello, > > >>Any idea which view is the correct one? > > > I would say - neither. Optimizations (pragma inline is supposed to be one) > sometimes do change the behavior of the program. For example on x86 you > can get different floating point results, depending on the optimization > level, and that's legal and logical. > > But in this case, if the compiler is unable to do both (pragma Inline, and > for X'Address) it should tell you about it, not fail at runtime. > > I think that using Unchecked_Conversion, instead of (ab)using 'Address rep > clause, will fix the problem. No abuse. 'Address is legal Ada. A novel or unexpected use does not mean that it 'abuses' the language. The current use allows the equivalent of a C/++ 'union'. Other C.L.A. communication shows this to be both a viable use and (to some) a good one. > > Oh, and why is Push a function? Why not? (Putting on my Pontifical Hat), I am the designer and Lord over my demesne. The historical root of this usage is from SLIP as described in PROGRAMMING SYSTEMS AND LANGUAGES McGraw-Hill Book Company Copyright 1967 Library of Congress # 66-29754 Author: Rosen Although written in FORTRAN II and somewhat dated, the core design is valid and provide an extensive set of tools to manipulate general lists. Part of the design is the use of return values to allow an application to nest function calls to generate a single useful result, as in 'Cell := Push(Push(datum));'. This format of algebraic is not much in use (for quite good reason) but as both legacy and currency it still deserves a place. > > Finally, inlining is often counter-productive, because it causes code size > explosion, which in turn causes CPU cache hit ratio degradation. In general this is accurate. The use of inlines in my case is carefully designed. It is expected that the inline subprograms will generate not code (will be optimized away) in the best case, and in the worst case, the overhead in code for subprogram entry and exit will be greater than or equal to the code within the subprogram. The performance should be more attractive. > > > Regards, > Wojtek The issue then seems to be that some of the semantics of an inline function can change, most particularly in the use of atomic numbers. But what else is affected? Thank you. art