Re: Semantics of Inline vs non-Inline

[Arthur Schwarz <aschwarz@acm.org>]

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