[M3devel] [M3commit] CVS Update: cm3

Tony Hosking hosking at cs.purdue.edu
Fri Jan 11 16:17:00 CET 2008


Certainly fixed in CM3.

On Jan 11, 2008, at 3:32 AM, Mika Nystrom wrote:

> This reminds me, there used to be a bug in PM3... has it been  
> fixed?  This code
> was unreliable:
>
> PROCEDURE P() =
>
>   VAR a : T;
>
>   PROCEDURE Q(b : U) =
>     BEGIN a := saveSomethingAbout(b) END Q;
>
>   BEGIN CallVisitor(Q) END P;
>
> (Note that the M3 report says that while inner procedures may not
> be assigned to variables, they may be passed as procedure parameters.
> The workaround for the compiler bug is to use something called
> "object-oriented programming".)
>
> "Rodney M. Bates" writes:
>> 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




More information about the M3devel mailing list