[M3devel] dbxout_static_chain_decl?

[hendrik at topoi.pooq.com]

On Thu, May 27, 2010 at 08:01:02PM -0500, Rodney M. Bates wrote:
>
>
> 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).

In Algol 68, when it's implemented using static links, the static chain 
doesn't thread *all* the chain of surrounding procedures -- it skips the 
ones that don't define any names used in the inner ones.

This bit of denesting might improve efficiency even in Modula 3, since 
some static chains might end up being shorter.  Whether it's worth the 
effort is another question, of course.

-- hendrik

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