[M3commit] CVS Update: cm3

[Tony Hosking]

Rodney,

Can you confirm that the static chains are now there for your  
purposes with the latest m3cc?  As far as I know, *any* nested  
procedure that might be called *will* now have a static chain  
generated for it.  I don't think I need to make any other changes to  
support this.  The reasoning is as follows: load_static_link is  
generated by the M3 front-end compiler whenever a nested function is  
called, and whenever a procedure value is created from a nested  
function -- ie, when passing a nested procedure as an actual -- since  
the value includes the static link as its environment.  This is what  
fixed p035 of m3tests.

-- Tony

On Jan 10, 2008, at 4:58 PM, Rodney M. Bates wrote:

> Antony, I can' tell from your posts whether this is what you did or  
> not, but:
>
> m3gdb really needs for there to be a static link allocated space  
> and stored, for
> _every_ nested procedure, even if there is nothing in the compiled  
> code that uses
> it.  m3gdb accesses/passes static links in several situations,  
> e.g., a user-typed
> call on a nested procedure constant, user-typed assignment of a  
> nested procedure
> value to a procedure variable, user-typed call on a procedure  
> variable (whose
> value might be nested or top-level), and just access to a variable  
> that is nonlocal
> to the current frame.
>
> All of this has been implemented for some time, although it is  
> distressingly
> fragile.  I have a number of times gone back in and fixed some case  
> I thought
> I had working earlier.  I recently started seeing "invalid static  
> link" messages
> again from m3gdb, after a hiatus.
>
> The variable access function is particularly important to me, as I  
> often use nested
> procedures, especially a recursive nested procedure inside a parent  
> that holds variables
> that are local to the whole recursive (dynamic) nest but not fully  
> global.  Especially when
> the recursion is umpteen levels deep, it is a real pain to have to  
> figure out how
> many levels to go "up" in the dynamic chain just to get to the  
> immediate static parent
> to print one of its variables. And if you want to type a expression  
> that mixes a local
> and a nonlocal variable, the feature is almost essential.
>
> So, I propose static links be there always, with the possible  
> exception of at very
> high optimization levels.
>
>
>
> Antony Hosking wrote:
>> CVSROOT:	/usr/cvs
>> Changes by:	hosking at birch.	08/01/07 20:20:48
>> Modified files:
>> 	cm3/m3-sys/m3cc/gcc/gcc/: tree-nested.c 	cm3/m3-sys/m3cc/gcc/gcc/ 
>> m3cg/: parse.c Log message:
>> 	Fix bug in procedure value comparison as revealed by p035 of  
>> m3tests.
>> 	The problem was that convert_all_function_calls was marking  
>> nested function
>> 	decls as *not* needing a static chain (DECL_NO_STATIC_CHAIN) when  
>> their bodies
>> 	and other nested procedures within them did not refer to any of  
>> their
>> 	variables.  In Modula-3 we still need the static chain (ie,  
>> procedure
>> 	environment) for procedure values so that they can be compared  
>> (tested
>> 	for equality) properly.  See the M3 language specification for  
>> details of
>> 	procedure types, which define a procedure as a triple, including its
>> 	environment.  The fix makes use of DECL_NONLOCAL on function  
>> decls to mark
>> 	them as needing the static chain to be preserved whenever a  
>> STATIC_CHAIN_EXPR
>> 	is created for the decl.
>
> -- 
> -------------------------------------------------------------
> Rodney M. Bates, retired assistant professor
> Dept. of Computer Science, Wichita State University
> Wichita, KS 67260-0083
> 316-978-3922
> rodney.bates at wichita.edu