The future of lambda delegates

[BCS]

Mikola Lysenko wrote:
> "BCS" <BCS at pathlink.com> wrote in message 
> news:ec2581$74o$2 at digitaldaemon.com...
> 
>>1) What happens when a heap based function calls a stack based function? 
>>Will the code try to extend the heap frame? [...]
> 
> 
> This would not present any sort of problem. Here is what a stack based 
> prolog looks like:
> 
> push EBP;                    //Save old frame pointer on the stack
> mov EBP, ESP;            //Set the new frame pointer & save stack pointer
> sub ESP, frame_size;    //Allocate the new frame from the stack
> 
> And when we exit, we use the following epilog:
> 
> mov ESP, EBP;            //Restore old stack pointer
> pop EBP;                     //Restore old frame pointer
> ret;                               //Resume execution from the previous 
> frame
> 
> In this case, it does not matter what EBP was before we entered the 
> function. [...]
> 

That may be so but IIRC EBP is generally modified by the function as it 
executes. This is done to make room for temporaries and such. This will 
present a problem because it will create a "phantom" stack frame. This 
could be dealt with by removing the EBP adjustment code from the 
function, but that would require changes to the code generator.

> 
>>2) heap frames only tackles the case where the "lost" scope is the 
>>function it's self. What about where the scope is a if block?
>>
>>void fn()
>>{
>>int i;
>>auto dg = {return i;};
>>if(i);
>>{
>>int j;
>>dg = {return i+j;};
>>}
>>if(i)
>>{
>>int k = 3;
>>k = dg(); // j overlaps k
>>}
>>}
> Typically all the variables used in a given function would get allocated in 
> the same frame.  In this case, the frame would look something like:
> 
> EBP[4] = return address
> EBP[0] = previous frame pointer
> EBP[-4] = i
> EBP[-8] = j
> EBP[-12] = k

This presents a problem, consider:

void fn()
{
	{
		int[BIG] big;
		use big
	}
	{
		float[HUGE] huge;
		use huge;
	}
}

In the general case (stack frames) these /should/ overlap. Otherwise the 
stack frame will become overly large. Heap frames could us a different 
layout, but again that will require changes the to code generator.

(BTW, I am now working on a machine that won't allow an int[1000] on the 
stack. So mandating that all stack variables be non overlapping in not 
an option.)


Both problems can be overcome, but I really don't like the idea of 
having the code generator produce different code for heap-frames and 
stack-frames.