comp.lang.ada
 help / color / mirror / Atom feed
From: Arthur Schwarz <aschwarz@acm.org>
Subject: Re: Semantics of Inline vs non-Inline
Date: Thu, 14 Oct 2004 17:49:40 -0700
Date: 2004-10-14T17:49:40-07:00	[thread overview]
Message-ID: <416F1EA4.5080700@acm.org> (raw)
In-Reply-To: <1427975.D57Qmkl0pE@linux1.krischik.com>

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
> 



  reply	other threads:[~2004-10-15  0:49 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <35f054ea.0410140733.5f250e6f@posting.google.com>
2004-10-14 16:14 ` Semantics of Inline vs non-Inline Wojtek Narczynski
2004-10-14 20:05   ` Arthur Schwarz
2004-10-15 10:24     ` Wojtek Narczynski
2004-10-15 16:32       ` Arthur Schwarz
2004-10-14 17:58 ` Martin Krischik
2004-10-15  0:49   ` Arthur Schwarz [this message]
2004-10-15  8:05     ` Martin Krischik
2004-10-15 16:39       ` Arthur Schwarz
2004-10-15 16:40       ` Arthur Schwarz
2004-10-15 16:40       ` Arthur Schwarz
2004-10-15 16:45       ` skidmarks
2004-10-15  3:40 ` Steve
2004-10-15  5:50 ` Simon Wright
2004-10-15 16:57   ` skidmarks
2004-10-18 17:01 ` skidmarks
2004-10-15  6:18 Christoph Karl Walter Grein
2004-10-15 11:02 ` Wojtek Narczynski
  -- strict thread matches above, loose matches on Subject: below --
2004-10-18  6:29 Christoph Karl Walter Grein
2004-10-20 15:07 ` Wojtek Narczynski
2004-10-21  5:07 Christoph Karl Walter Grein
2004-10-21 10:24 ` Wojtek Narczynski
2004-10-21 11:21 Christoph Karl Walter Grein
2004-10-21 20:57 ` Wojtek Narczynski
2004-10-22  0:46 ` skidmarks
2004-10-22  5:50   ` Simon Wright
2004-10-22 12:57     ` Wojtek Narczynski
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox