[M3devel] dbxout_static_chain_decl?

[Rodney M. Bates]

Jay K wrote:
> Shouldn't gcc be able to optimize about as well any such transform?
>   Or would we tend to produce a bunch of structs, take their address, gcc would be strongly inlined to not enregister them and such?
>  
> Anyway, ok.
>  
> There's stuff I have to figure out and understand here either way.
>  
> Like, does the the static chain "flow" through non-nested calls?

The static chain flows through a series of activation records of calls
on progressively more shallowly nested procedures, until the last link
in the chain leads to an activation of a non-nested procedure.  Here the
static chain ends.

Conceptually, it would be convenient and consistent to think of this non-nested
procedure as having one more static link pointing to an area where all global
variables are stored, but in reality, almost no runtime addressing model does this.
Since globals have whole-program lifetime and always exactly one instance,
it is better to address them in some other way.

Note the static chain is needed for nested procedures even if there
are no procedure variables or parameters.  (e.g. Ada).

>  
>  - Jay
> 
> 
> ________________________________
>> From: hosking at cs.purdue.edu
>> Date: Thu, 27 May 2010 05:27:56 -0400
>> To: jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] dbxout_static_chain_decl?
>>
>>
>>
>> Argh!!!!!
>> No! We don't want to do work in the front-end to get rid of nesting.
>> It is terribly important for performance (e.g., register allocation) that we retain the gcc-based support.
>>
>>
>>
>>
>> Antony Hosking | Associate Professor | Computer Science | Purdue University
>> 305 N. University Street | West Lafayette | IN 47907 | USA
>> Office +1 765 494 6001 | Mobile +1 765 427 5484
>>
>>
>>
>>
>>
>>
>> On 26 May 2010, at 18:53, Jay K wrote:
>>
>>
>> Rodney, When you get back to it, can you just dig it out of history?
>>
>>
>> I still think we should try to avoid gcc's nested function functionality.
>>
>>
>> Where you use the static chain, not using the nested function functionality should
>> "automatically" be debuggable -- "automatic" as in, once the work is done
>> in the frontend to transform out nesting.
>>
>>
>> "debuggable" as in, you could follow the links yourself in the debugger.
>> The debugger need not search lexically nested functions that have function
>> calls dividing them.
>>
>>
>> ?
>>
>>
>> There's stuff I still need to understand better -- particularly the affect of nested functions
>> on non-nested functions. Is there *always* an extra parameter to *all* functions?
>> It appears so.
>> And I haven't figured out how to merge with 4.5 what I think achieves that.
>>
>>
>> Maybe a good test of test cases here?
>>
>>
>>
>> - Jay
>>
>>
>> ----------------------------------------
>> Date: Wed, 26 May 2010 17:37:07 -0500
>> From: rodney_bates at lcwb.coop
>> To: m3devel at elegosoft.com
>> Subject: Re: [M3devel] dbxout_static_chain_decl?
>>
>> I left it in because it is a work in progress. I *really* want to get it to
>> work, and I don't what to have to reinvent what is already there when I get
>> to it. I use nested procedures extensively in certain situations, and good
>> debugger support of them is important to me. It all works fine on older code
>> generators than the gcc that added tree-nested.c.
>>
>> Jay K wrote:
>> Rodney, you added this function, along with a comment that says it doesn't actually work.
>> Does it work?
>> Does it accomplish anything?
>> Can I remove it and its calls?
>>
>> /* Special-purpose function to write stabs for the static_chain_decl.
>> So far, this is not working. m3gdb needs the place in the activation
>> record where the SL is stored. Right now, the SL is not necessarily
>> stored at all, but may just be kept in a register. DECL_RTL and
>> DECL_INCOMING_RTL may both have register expressions. But stabs
>> entries for register variables, of kind N_RSYM, are currently ignored
>> by gdb in dbxread.c, and making it read them could create problems
>> elsewhere, because there can be other variables for which both an
>> N_RSYM and an N_LSYM stabs entry are created.
>> */
>> static int
>> dbxout_static_chain_decl (tree decl)
>>
>> It was added 19 months ago by:
>> http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3cc/gcc/gcc/dbxout.c.diff?r1=1.8;r2=1.9
>>
>> as well, do we need the #if 0 code added then?
>>
>> - Jay
>>
>>