[M3devel] m3cc static chain stuff

[Jay K]

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