[M3devel] m3cc static chain stuff

[Rodney M. Bates]

More concerning tree-nested.c:

I am now remembering that there was some inconsistent terminology in
tree-nested.c, calling the same thing by different names, etc, in
comments, and, I think, in some identifiers too.  One thing I did
was clean this up, after having to unravel it for the second time,
not remembering it all from the first time.

If history is any guide, just moving to a newer base gcc will no
doubt break several things in m3gdb, and I'll probably be the logical
one to do most of that part of the patching.


Jay K wrote:
> Ok ok let me explain my "real" questions.
>  
>  
>  
>  - Can someone show me an example (or add a test case) that demonstrates the "full" functionality of nested functions, pointers to them, comparing said pointers for equality, and recursion?
>  
>  
>  
> and/or
>  
>  
>  
>  
>  - Can someone show me how the above translates to C?
>    Or Modula-3 with no nested functions.
>    Using Modula-3 closures.
>    It's not about the syntax, it's about a lower level model.
>    Bonus points if you can show me the translation to C-like code with gcc trampolines also.
>      That's mainly currently just for curiosity.
>  
>  
>  
> and/or
>  
>  
>  
>  - Can someone explain to me all of our changes to tree-nested.c. Not that there is much, granted.
>  
>  
>  
> Like, I need to understand what to do for gcc 4.5.0.
>  
>  
> Some of the tree-nested changes refer to a particular test case.
> I'll look there to start.
>  
>  
>  
> In 4.3 tree-nested we do something, like, visit everything, and change some of the things.
> With a comment that maybe we could do it better.
> The context in 4.5 is vastly different now.
> The 4.3 changes "completely unmergable".
>   I even looked around for somewhere else to put them.
>  
>  
>  
> Ultimately I might succeed through "force of pattern matching", but I'd kinda like to understand as well.
>  Even some of the dbxout.c stuff I don't understand, but it appears to merge easily so probably ok.
>  
>  
>  
> I'll see if I can get some clues here:
>   http://gcc.gnu.org/onlinedocs/gccint/
>  
>  
> :)
>  
>  
>  - Jay
> 
> 
> 
> 
> ----------------------------------------
>> Date: Fri, 28 May 2010 18:07:20 -0400
>> From: hendrik at topoi.pooq.com
>> To: m3devel at elegosoft.com
>> Subject: Re: [M3devel] m3cc static chain stuff
>>
>> On Wed, May 26, 2010 at 06:04:42PM -0500, Rodney M. Bates wrote:
>>>
>>> Jay K wrote:
>>>>> From: hosking at cs.purdue.edu
>>>>> Date: Wed, 26 May 2010 10:28:51 -0400
>>>>> To: jay.krell at cornell.edu
>>>>> CC: m3devel at elegosoft.com
>>>>> Subject: Re: [M3devel] m3cc static chain stuff
>>>>>
>>>>>
>>>>>
>>>>> We should endeavour to use the same functionality that the C compiler
>>>>> uses for its own nested functions,
>>> whereever possible. The only thing is that we also build closures, so the trampoline mechanisms should be avoided.
>>>>
>>>> Right..for those that don't know..
>>>>
>>>>
>>>> There's no "good" efficient way to implement nested functions.
>>>> Our implementation is pretty "bad".
>>>> gcc's implementation is pretty "bad".
>>> I think this is far too critical. The inefficiencies you see are
>>> minor. Certainly no worse than the implementation of dispatching
>>> methods of objects, something the world is gaga about.
>> Sufficiently gaga that hardware manufacturers are trying to make it
>> really fast. Things like fetch- and branch- prediction.
>>
>> We may as well use them if there isn't something better around.
>>
>> -- hendrik