Re: Semantics of Inline vs non-Inline

Re: Semantics of Inline vs non-Inline

[Wojtek Narczynski]

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.

Oh, and why is Push a function?

Finally, inlining is often counter-productive, because it causes code size
explosion, which in turn causes CPU cache hit ratio degradation.


Regards,
Wojtek

Re: Semantics of Inline vs non-Inline

[Martin Krischik]

skidmarks wrote:

> My compiler vendor says that the semantics of an inline/non-inline
> function can be different at the discretion of the compiler vendor. In
> particular, if at the point of use of an inline function the value of
> an argument (to the defined subprogram) is in a register, then it is
> acceptable to 'crash' because the address of the argument is not known
> (it's in a register).
> 
> My claim is that the semantics of of an inline and non-inline
> subprogram must be identical, and further, the application writer is
> both unaware and should be unaware of the code generated at the point
> of subprogram use.
> 
> Any idea which view is the correct one?
> 
> Art
> 
> ----------------------------------------------------------
> Example (in truncated pseudo-Ada):
> 
> package body x is
>    subtype Datum_Type is Natural;
>    package List is new abc.List_Manager( <size> );
>    function Push( Datum : Datum_Type ) return List.Cell_Ptr is
>       LM_Datum : List.Datum_Type;
>                  for LM_Datum'Address use Datum'Address;
>    begin -- Push
>      return List.Push(LM_Datum);
>    end Push;
>    pragma inline( Push );
> 
>    Cell : List.Cell_Ptr;
>    thing: Natural;
> begin -- x
>    Cell := Push(thing);
> end x;
> 
> This code does not work with    'pragma inline'.
> This code does     work without 'pragma inline'.
> 
> The vendor claims that the address of 'thing' is not known at the call
> (it may be in a register) and hence the inlined 'Push' does not have a
> valid input argument. My first statement is that the behavior for
> inline/non-inline should be the same, and that if it succeeds in one
> it should succeed in all. Is this a correct interpretation?

1st: only aliased data is guaranteed to have an 'Address. Even non inline
functions may use a register for certain data.

2nd: You must see 'Address as some form of Unchecked_Conversion - actually
the way you have used 'Address it is Unchecked_Unchecked_Conversion -
that's is the way a "reinterpret_cast <>" (if you know C++) is done in Ada.

With Regards

Martin

-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: Semantics of Inline vs non-Inline

[Arthur Schwarz]

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

Re: Semantics of Inline vs non-Inline

[Arthur Schwarz]

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
> 

Re: Semantics of Inline vs non-Inline

[Steve]

For what it's worth I am in full agreement with your claim.  Inline
expansion of subprograms is described in section 6.3.2 of the Ada 95
Reference manual.

No special considerations are given for accessability of values and in fact
the compiler is explicity given permission to ignore the inline
recommendation.  I would agree that if the code fails with the inline pragma
and succeeds otherwise, the compiler is broken.  Of course I'm not an
authority.

Steve
(The Duck)

"skidmarks" <aschwarz@acm.org> wrote in message
news:35f054ea.0410140733.5f250e6f@posting.google.com...
> My compiler vendor says that the semantics of an inline/non-inline
> function can be different at the discretion of the compiler vendor. In
> particular, if at the point of use of an inline function the value of
> an argument (to the defined subprogram) is in a register, then it is
> acceptable to 'crash' because the address of the argument is not known
> (it's in a register).
>
> My claim is that the semantics of of an inline and non-inline
> subprogram must be identical, and further, the application writer is
> both unaware and should be unaware of the code generated at the point
> of subprogram use.
>
> Any idea which view is the correct one?
>
> Art
>
> ----------------------------------------------------------
> Example (in truncated pseudo-Ada):
>
> package body x is
>    subtype Datum_Type is Natural;
>    package List is new abc.List_Manager( <size> );
>    function Push( Datum : Datum_Type ) return List.Cell_Ptr is
>       LM_Datum : List.Datum_Type;
>                  for LM_Datum'Address use Datum'Address;
>    begin -- Push
>      return List.Push(LM_Datum);
>    end Push;
>    pragma inline( Push );
>
>    Cell : List.Cell_Ptr;
>    thing: Natural;
> begin -- x
>    Cell := Push(thing);
> end x;
>
> This code does not work with    'pragma inline'.
> This code does     work without 'pragma inline'.
>
> The vendor claims that the address of 'thing' is not known at the call
> (it may be in a register) and hence the inlined 'Push' does not have a
> valid input argument. My first statement is that the behavior for
> inline/non-inline should be the same, and that if it succeeds in one
> it should succeed in all. Is this a correct interpretation?

Re: Semantics of Inline vs non-Inline

[Simon Wright]

aschwarz@acm.org (skidmarks) writes:

> My compiler vendor says that the semantics of an inline/non-inline
> function can be different at the discretion of the compiler
> vendor. In particular, if at the point of use of an inline function
> the value of an argument (to the defined subprogram) is in a
> register, then it is acceptable to 'crash' because the address of
> the argument is not known (it's in a register).
> 
> My claim is that the semantics of of an inline and non-inline
> subprogram must be identical, and further, the application writer is
> both unaware and should be unaware of the code generated at the
> point of subprogram use.
> 
> Any idea which view is the correct one?

I can see that those aspects of execution that aren't defined by the
language, or which are erroneous, could be affected by inlining. At
the very least the sequence of instructions is going to be different.

GNAT has occasionally told me that something couldn't be inlined
because of some feature of my code, and I would expect at the least
that this would happen here. (I suspect your code is much cut down, a
simple test here shows no problem -- 3.16a1).

But, the variable only got into the register because the compiler
backend put it there, you would have thought the backend would say
"can I leave this variable into a register? oh no, I see I need
'Address, better spill it to store".

I think your claim sounds 100% right. And even if I'm wrong, the
vendor's view seems less than helpful. The compiler ought to _try_ to
do the Right Thing.

-- 
Simon Wright                               100% Ada, no bugs.

Re: Semantics of Inline vs non-Inline

[Christoph Karl Walter Grein]

> 
The question here is not "Inline vs. not Inline", but "is 'Address attribute guaranteed to deliver 
correct results".

RM 13.3(13) says it's the programmer's responsibility to ensure the address is valid.
RM 13.3(15..18) specify the recommended level of support.

Your parameter "Datum: Datum_Type" is not in this list:
Datum_Type is not a by-reference type.

If your program works non-inlined, you are just lucky. Your compiler vendor is right.
________________________________________________________________
Verschicken Sie romantische, coole und witzige Bilder per SMS!
Jetzt neu bei WEB.DE FreeMail: http://freemail.web.de/?mc=021193

Re: Semantics of Inline vs non-Inline

[Martin Krischik]

Arthur Schwarz wrote:

> 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.

>    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.

Yes. Depending on compiler/cpu the non inlined version might not work
either. Unless you use some representation clause the compiler has a lot of
freedom to perform the parameter passing. You need to ensure the data does
indeed have an address.

i.E.:

ￜￜￜfunctionￜPush(ￜDatumￜ:ￜaccess Datum_Typeￜ)ￜreturnￜList.Cell_Ptrￜis
ￜￜￜￜￜￜLM_Datumￜ:ￜList.Datum_Type;
ￜￜￜￜￜￜￜￜￜￜￜￜￜￜￜￜￜforￜLM_Datum'AddressￜuseￜDatum.all'Address;
ￜￜￜbeginￜ--ￜPush
ￜￜￜￜￜreturnￜList.Push(LM_Datum);
ￜￜￜendￜPush;
ￜￜￜpragmaￜinline(ￜPushￜ);

By passing an access you force the compiler to make sure an address is
available. 

>    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.

Yes, they should both fail. Again: only aliased data is guaranteed to have
an 'Address. There are rules in Ada for Pass by Reference and Free to
Choose. Free to Choose is the largest group.

Pass on Stack is only needed for "Pragma Export" and "Pragma Import". So an
PowerPC or 68xxxx CPU which have lots of registers even the non inlined
version may use register and pass by copy for parameter passing.

>    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.

The non inlined version only works because you where luck. However, there is
just one thing where you should go back to your verndor and insist on a bug
to be fixed: PROGRAM_ERROR should have been raised. And most compilers
issue a warning when the code for PROGRAM_ERROR is generated. 

With Regards

Martin
-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: Semantics of Inline vs non-Inline

[Wojtek Narczynski]

Hello,

>> 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.

I cannot agree to that. It is a totally unchecked conversion of anything
into anything (GNAT is kind enough to do some checks voluntarily). This is
the way to defeat the Ada type system. It is mostly used to overcome the
lack of 'out' parameters for functions. And we're just discussing a case
where the use of 'Address led to a runtime crash.

For C++ like unions you'll have pragma Unchecked_Union in Ada 2005.
 
>> Oh, and why is Push a function?
> 
>    Why not?
>
>    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.

Okay, that's nice.


Regards,
Wojtek

Re: Semantics of Inline vs non-Inline

[Wojtek Narczynski]

Hello,

> The question here is not "Inline vs. not Inline", but "is 'Address attribute 
> guaranteed to deliver correct results".

Okay.

> RM 13.3(15..18) specify the recommended level of support.

Those paragraphs do not mandate returning a rubbish address for unsuported
cases. Also please note that if you use other attributes in context where
it does not make sense, the compiler will tell you about it.

> RM 13.3(13) says it's the programmer's responsibility to ensure the
> address is valid.

"If an Address is specified, it is the programmer's responsibility to
ensure that the address is valid; otherwise, program execution is
erroneous."

This does not say anything about when 'Address produces correct result, it
only says that in "for X'Address use <XXXXX>", you're supposed to provide
correct <XXXXX>.

Regards,
Wojtek

Re: Semantics of Inline vs non-Inline

[Arthur Schwarz]

"Wojtek Narczynski" <wojtek@power.com.pl> wrote in message
news:pan.2004.10.15.10.24.40.759156@power.com.pl...
> Hello,
>
> >> 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.
>
> I cannot agree to that. It is a totally unchecked conversion of anything
> into anything (GNAT is kind enough to do some checks voluntarily). This is
> the way to defeat the Ada type system. It is mostly used to overcome the
> lack of 'out' parameters for functions. And we're just discussing a case
> where the use of 'Address led to a runtime crash.

  Well at this point we must respectfully disagree. I understand you
objection
  and don't take issue with it. Outside of LRM statements   prohibiting use
or
  mandating specific use, then the user is free to choose. I do not disagree
  that (in this case) this defeats the safety checks in Ada. I do disagree
with
  the notion that as a non-prohibited use it should be consigned to 'just
  deserved oblivion'. Sigh.

  And thank you again. You and Martin, the other respondent, have provided
  some alternatives which may relieve me of this problem.

art

Re: Semantics of Inline vs non-Inline

[Arthur Schwarz]

"Martin Krischik" <krischik@users.sourceforge.net> wrote in message
news:6545303.EbTl0XcSZp@linux1.krischik.com...
> Arthur Schwarz wrote:
>
> > Martin Krischik wrote:
> >
> >> skidmarks wrote:
> function Push( Datum : access Datum_Type ) return List.Cell_Ptr is
> LM_Datum : List.Datum_Type;
> for LM_Datum'Address use Datum.all'Address;
> begin -- Push
> return List.Push(LM_Datum);
> end Push;
> pragma inline( Push );
>
> By passing an access you force the compiler to make sure an address is
> available.

  A clue, a clue. Thank you. This (and the other suggestions by you and the
  other comp.lang.ada respondent) will be tried.

  Does this mean that I pass an access type or indicate, to the compiler,
that
  the compiler should generate code such that a valid address is available?
>
> The non inlined version only works because you where luck. However, there
is
> just one thing where you should go back to your verndor and insist on a
bug
> to be fixed: PROGRAM_ERROR should have been raised. And most compilers
> issue a warning when the code for PROGRAM_ERROR is generated.

  The vendor is in a state of denial. They deny that this is a bug (as,
sigh, do you)
  and may well not see that if it is not a bug, then the application is due
a diagnostic
  message. Sic caveat emptor.
>
> With Regards
>
> Martin

  Thank you. I don't like your answer (drat) but I'm equally sure it is
correct. And
  you have provided fruitful ways for me to explore the underside of Ada and
  perhaps repair this error. (And I do apologize for misspelling,
missgrammer,
  and all other miss's).

art

Re: Semantics of Inline vs non-Inline

[Arthur Schwarz]

"Martin Krischik" <krischik@users.sourceforge.net> wrote in message
news:6545303.EbTl0XcSZp@linux1.krischik.com...
> Arthur Schwarz wrote:
>
> > Martin Krischik wrote:
> >
> >> skidmarks wrote:
> function Push( Datum : access Datum_Type ) return List.Cell_Ptr is
> LM_Datum : List.Datum_Type;
> for LM_Datum'Address use Datum.all'Address;
> begin -- Push
> return List.Push(LM_Datum);
> end Push;
> pragma inline( Push );
>
> By passing an access you force the compiler to make sure an address is
> available.

  A clue, a clue. Thank you. This (and the other suggestions by you and the
  other comp.lang.ada respondent) will be tried.

  Does this mean that I pass an access type or indicate, to the compiler,
that
  the compiler should generate code such that a valid address is available?
>
> The non inlined version only works because you where luck. However, there
is
> just one thing where you should go back to your verndor and insist on a
bug
> to be fixed: PROGRAM_ERROR should have been raised. And most compilers
> issue a warning when the code for PROGRAM_ERROR is generated.

  The vendor is in a state of denial. They deny that this is a bug (as,
sigh, do you)
  and may well not see that if it is not a bug, then the application is due
a diagnostic
  message. Sic caveat emptor.
>
> With Regards
>
> Martin

  Thank you. I don't like your answer (drat) but I'm equally sure it is
correct. And
  you have provided fruitful ways for me to explore the underside of Ada and
  perhaps repair this error. (And I do apologize for misspelling,
missgrammer,
  and all other miss's).

art

Re: Semantics of Inline vs non-Inline

[Arthur Schwarz]

"Martin Krischik" <krischik@users.sourceforge.net> wrote in message
news:6545303.EbTl0XcSZp@linux1.krischik.com...
> Arthur Schwarz wrote:
>
> > Martin Krischik wrote:
> >
> >> skidmarks wrote:
> function Push( Datum : access Datum_Type ) return List.Cell_Ptr is
> LM_Datum : List.Datum_Type;
> for LM_Datum'Address use Datum.all'Address;
> begin -- Push
> return List.Push(LM_Datum);
> end Push;
> pragma inline( Push );
>
> By passing an access you force the compiler to make sure an address is
> available.

  A clue, a clue. Thank you. This (and the other suggestions by you and the
  other comp.lang.ada respondent) will be tried.

  Does this mean that I pass an access type or indicate, to the compiler,
that
  the compiler should generate code such that a valid address is available?
>
> The non inlined version only works because you where luck. However, there
is
> just one thing where you should go back to your verndor and insist on a
bug
> to be fixed: PROGRAM_ERROR should have been raised. And most compilers
> issue a warning when the code for PROGRAM_ERROR is generated.

  The vendor is in a state of denial. They deny that this is a bug (as,
sigh, do you)
  and may well not see that if it is not a bug, then the application is due
a diagnostic
  message. Sic caveat emptor.
>
> With Regards
>
> Martin

  Thank you. I don't like your answer (drat) but I'm equally sure it is
correct. And
  you have provided fruitful ways for me to explore the underside of Ada and
  perhaps repair this error. (And I do apologize for misspelling,
missgrammer,
  and all other miss's).

art

Re: Semantics of Inline vs non-Inline

[skidmarks]

"Martin Krischik" <krischik@users.sourceforge.net> wrote in message news:6545303.EbTl0XcSZp@linux1.krischik.com...
> Arthur Schwarz wrote:
> 
> > Martin Krischik wrote:
> > 
> >> skidmarks wrote:
> function Push( Datum : access Datum_Type ) return List.Cell_Ptr is
> LM_Datum : List.Datum_Type;
> for LM_Datum'Address use Datum.all'Address;
> begin -- Push
> return List.Push(LM_Datum);
> end Push;
> pragma inline( Push );
> 
> By passing an access you force the compiler to make sure an address is
> available. 

  A clue, a clue. Thank you. This (and the other suggestions by you and the
  other comp.lang.ada respondent) will be tried.

  Does this mean that I pass an access type or indicate, to the compiler, that
  the compiler should generate code such that a valid address is available?
> 
> The non inlined version only works because you where luck. However, there is
> just one thing where you should go back to your verndor and insist on a bug
> to be fixed: PROGRAM_ERROR should have been raised. And most compilers
> issue a warning when the code for PROGRAM_ERROR is generated. 

  The vendor is in a state of denial. They deny that this is a bug (as, sigh, 
  do you) and may well not see that if it is not a bug, then the application is
  due a diagnostic message. Sic caveat emptor.
> 
> With Regards
> 
> Martin

  Thank you. I don't like your answer (drat) but I'm equally sure it is correct.
  And you have provided fruitful ways for me to explore the underside of Ada and
  perhaps repair this error. (And I do apologize for misspelling, missgrammer,
  and all other miss's).

art

Re: Semantics of Inline vs non-Inline

[skidmarks]

Simon Wright <simon@pushface.org> wrote in message news:<x7vpt3k34yp.fsf@smaug.pushface.org>...

> GNAT has occasionally told me that something couldn't be inlined
> because of some feature of my code, and I would expect at the least
> that this would happen here. (I suspect your code is much cut down, a
> simple test here shows no problem -- 3.16a1).

 (I love GNAT). I'm using gcc-3.3.3-3 with gnat included. And as for 
 you, it works. (I suspect some, maybe all, of my 'vendor's pique is
 because I had the temerity to include the GNAT generated .exe, .ali
 and .o files - the vendor said: "oh well").

 Actually, the simple test case is sufficient to illustrate the issues.
 The thing that sticks in my craw is that I cleverly design a List 
 Manager so that the management functions were separated from the 
 application and data specific operations. (Some) application specific
 behaviors were provided in a generic, and if insufficient, the application
 must provide others in the code. However, it is expected that the 
 expanded inline subprograms would generate no code. Instead, the 
 subprograms are developed to isolate areas of concern, a la Ada, but
 not effect performance. If the errant subprograms can not be inlined,
 there will be a performance hit. The design is sturdy and will be
 maintained. But the inclusion of multiple layers of subprogram calls
 effects performance. From my viewpoint, it is important to resolve
 this so that inline code can be used (others on this thread have
 provided 'clues' or workarounds which I will try).

 Bye the bye, I've spent last several years trying to get management
 buyin on the use of 'free' software. No buying. Statements that
 the company can always provide support are unavailing.

Thank you

art

Re: Semantics of Inline vs non-Inline

[Christoph Karl Walter Grein]

From: Wojtek Narczynski <wojtek@power.com.pl>

> > RM 13.3(15..18) specify the recommended level of support.
> 
> Those paragraphs do not mandate returning a rubbish address for unsuported
> cases. Also please note that if you use other attributes in context where
> it does not make sense, the compiler will tell you about it.

When you're going outside the recommended level of support, you're on your own and can't blame the compiler
vendor. It's a nice feature if you get a warning. And ACT is very open to proposals for better compiler messages.
(I do not know who the compiler vendor of the OP is.)

> > RM 13.3(13) says it's the programmer's responsibility to ensure the
> > address is valid.
> 
> "If an Address is specified, it is the programmer's responsibility to
> ensure that the address is valid; otherwise, program execution is
> erroneous."
> 
> This does not say anything about when 'Address produces correct result, it
> only says that in "for X'Address use <XXXXX>", you're supposed to provide
> correct <XXXXX>.

  function Push( Datum : Datum_Type ) return List.Cell_Ptr is
     LM_Datum : List.Datum_Type;
     for LM_Datum'Address use Datum'Address;

And here, no correct <XXXXX> is provided. So RM 13.3(13) is violated. Therefore the program is erroneous.

Erroneous means: The compiler need not detect this. If it doesn't, the program is free to do anything. The (in)famous
nasal demons :-)
________________________________________________________________
Verschicken Sie romantische, coole und witzige Bilder per SMS!
Jetzt neu bei WEB.DE FreeMail: http://freemail.web.de/?mc=021193

Re: Semantics of Inline vs non-Inline

[skidmarks]

Well, thanks. The results of your efforts are that I am successful.
Here is the update.

1. Unchecked_Conversion was tried and worked. funct( a: access type)
was briefly tried but in this case I think that Unchecked_Conversion
is the better choice.

2. I mispoke about not receiving an appropriate error message from the
compiler. The compiler did indeed say that it couldn't find a valid
address, that 'null' was to be substituted, and that there would be a
run-time constraint error. However, at run-time Windows captured and
reported the error, not the Ada run-time system.

At the end, there is success in effort and a (vast) improvement in
understanding. Thank you all again.

art

(And the vendor does still insist that their compiler is operating
correctly. The vendor's representative did point out that there was
indeed an appropriate diagnostic message, and on his behalf I am sorry
that I was inaccurate.)

Re: Semantics of Inline vs non-Inline

[Wojtek Narczynski]

>   function Push( Datum : Datum_Type ) return List.Cell_Ptr is
>      LM_Datum : List.Datum_Type;
>      for LM_Datum'Address use Datum'Address;

Sorry, I still don't see why Datum'Address should compile if it is not supported.

Regards,
Wojtek

Re: Semantics of Inline vs non-Inline

[Christoph Karl Walter Grein]

> >   function Push( Datum : Datum_Type ) return List.Cell_Ptr is
> >      LM_Datum : List.Datum_Type;
> >      for LM_Datum'Address use Datum'Address;
> 
> Sorry, I still don't see why Datum'Address should compile if it is not supported.
> 
> Regards,
> Wojtek

Obviously you are not familiar with Ada RM speak:

"Not supported" means: Upon execution of your program, it's undefined what will happen.
If your compiler does not pass the argument with a valid address, your program is erroneous.
Full stop.

The RM also makes a distinction between "undefined" and "implementation defined".

But your program is legal syntax, so the compiler cannot reject it. As it cannot reject X := 1 / 0;

It might do you a favour and output a warning, though, but that's not required.
________________________________________________________________
Verschicken Sie romantische, coole und witzige Bilder per SMS!
Jetzt neu bei WEB.DE FreeMail: http://freemail.web.de/?mc=021193

Re: Semantics of Inline vs non-Inline

[Wojtek Narczynski]

On Thu, 21 Oct 2004 07:07:31 +0200, Christoph Karl Walter Grein wrote:

>> >   function Push( Datum : Datum_Type ) return List.Cell_Ptr is
>> >      LM_Datum : List.Datum_Type;
>> >      for LM_Datum'Address use Datum'Address;
>> 
>> Sorry, I still don't see why Datum'Address should compile if it is 
>> not supported.
>>
>> Regards,
>> Wojtek
> 
> Obviously you are not familiar with Ada RM speak:

Indeed.

> "Not supported" means: Upon execution of your program, it's undefined what
> will happen.

I am right now grepping the RM, and this is just not true. The RM defines
in dozens of places what should happen if something is "not supported".
For example, applicable to this case:

"13/1 A representation or operational item that is not supported by the
implementation is illegal, or raises an exception at run time."

Regards,
Wojtek

Re: Semantics of Inline vs non-Inline

[Christoph Karl Walter Grein]

> > "Not supported" means: Upon execution of your program, it's undefined what
> > will happen.
> 
> I am right now grepping the RM, and this is just not true. The RM defines
> in dozens of places what should happen if something is "not supported".
> For example, applicable to this case:
> 
> "13/1 A representation or operational item that is not supported by the
> implementation is illegal, or raises an exception at run time."

OK, I stand corrected. But didn't you say your procedure, when inlined, produced
an exception (and worked when not inlined)?

Only if it didn't, you have a point against your compiler vendor and should push his nose to
this pragraph.
__________________________________________________________
Mit WEB.DE FreePhone mit hoechster Qualitaet ab 0 Ct./Min.
weltweit telefonieren! http://freephone.web.de/?mc=021201

Re: Semantics of Inline vs non-Inline

[Wojtek Narczynski]

>> "13/1 A representation or operational item that is not supported by the
>> implementation is illegal, or raises an exception at run time."
> 
> OK, I stand corrected. But didn't you say your procedure, when inlined, 
> produced an exception (and worked when not inlined)?

I am not the original poster, the original poster claims the program
'crashes'.

Regards,
Wojtek

Re: Semantics of Inline vs non-Inline

[skidmarks]

"Christoph Karl Walter Grein" <AdaMagica@web.de> wrote in message news:<mailman.43.1098357729.10401.comp.lang.ada@ada-france.org>...

> Only if it didn't, you have a point against your compiler vendor and should push his nose to
> this pragraph.

Two points:
1. A warning message was issued stating that a 'null' value would
   be substituted for the input address, and
2. At run-time, the error was caught with Windows not Ada.

here has been mention that for the case at point, the compiler is not
correct (both 1. and 2. are erroneous) and also that the compiler is
correct (1. is correct and 2. is erroneous).

For respondents not literate in the LRM but, nonetheless trying to
produce a product, the feeling is that 1. and 2. are erroneous. This
includes myself.

art

Re: Semantics of Inline vs non-Inline

[Simon Wright]

aschwarz@acm.org (skidmarks) writes:

> "Christoph Karl Walter Grein" <AdaMagica@web.de> wrote in message news:<mailman.43.1098357729.10401.comp.lang.ada@ada-france.org>...
> 
> > Only if it didn't, you have a point against your compiler vendor
> > and should push his nose to this pragraph.
> 
> Two points:
> 1. A warning message was issued stating that a 'null' value would
>    be substituted for the input address, and
> 2. At run-time, the error was caught with Windows not Ada.
> 
> here has been mention that for the case at point, the compiler is not
> correct (both 1. and 2. are erroneous) and also that the compiler is
> correct (1. is correct and 2. is erroneous).
> 
> For respondents not literate in the LRM but, nonetheless trying to
> produce a product, the feeling is that 1. and 2. are erroneous. This
> includes myself.

1 cannot be erroneous, because erroneous is about what happens at run
time to your incorrect program, not about compiler messages.

2 is a perfectly legit response to an erroneous program.

"erroneous" does NOT mean exactly the same as "wrong" or "not what I
wanted". In an Ada context, it has a specific meaning. See ARM
1.1.5(10):

   "In addition to bounded errors, the language rules define certain
   kinds of errors as leading to erroneous execution. Like bounded
   errors, the implementation need not detect such errors either prior
   to or during run time. Unlike bounded errors, there is no
   language-specified bound on the possible effect of erroneous
   execution; the effect is in general not predictable."

-- 
Simon Wright                               100% Ada, no bugs.

Re: Semantics of Inline vs non-Inline

[Wojtek Narczynski]

Simon Wright <simon@pushface.org> wrote in message news:<x7vk6tjqp2m.fsf@smaug.pushface.org>...

Just replace the adjective 'erroneous' with 'defective' 

http://dictionary.reference.com/search?q=defective

In the light of RM 13/1 the compiler in question is defective.

IMHO :-)

Regards,
Wojtek