Re: nested functions

Ian Lance Taylor <ian@airs.com>
30 Aug 2006 14:11:58 -0400

          From comp.compilers

Related articles
nested functions reji_thomas@symantec.com (2006-08-29)
Re: nested functions tommy.thorn@gmail.com (Tommy Thorn) (2006-08-30)
Re: nested functions ian@airs.com (Ian Lance Taylor) (2006-08-30)
Re: nested functions torbenm@app-0.diku.dk (2006-08-30)
Re: nested functions tommy.thorn@gmail.com (Tommy Thorn) (2006-08-30)
Re: nested functions reji_thomas@symantec.com (2006-08-31)
Re: nested functions tommy.thorn@gmail.com (Tommy Thorn) (2006-08-31)
Re: nested functions marcov@stack.nl (Marco van de Voort) (2006-09-06)
Re: nested functions tommy.thorn@gmail.com (Tommy Thorn) (2006-09-06)
[5 later articles]
| List of all articles for this month |

From: Ian Lance Taylor <ian@airs.com>
Newsgroups: comp.compilers
Date: 30 Aug 2006 14:11:58 -0400
Organization: Compilers Central
References: 06-08-140
Keywords: code, design, functional
Posted-Date: 30 Aug 2006 14:11:58 EDT

reji_thomas@symantec.com writes:


> From my understanding, a compiler uses
>
> 1. Lambda lifting where the nested function is hoisted to global level
> passing free variables through an env pointer or as explicit arguments.
>
> 2.Static chaining or displays which uses pointers to the corresponding
> stackframe in which the non local variable is defined.
>
>
> One of my questions is
>
> whether lambda lifting cannot solve any cases which chaining/displays
> can only solve?.


As far as I know lambda lifting will always work. But you do have to
do some extra work in some cases. Consider:


extern void bar(void (*pfn)(int));
void foo(int j)
{
    void inner(int i) { return i + j; }
    bar(inner);
}


The only way to lambda lift inner is to pass in the address of j. But
then the resulting function expects two parameters, so it won't work
to pass it to bar. So you need to dynamically build a trampoline
function which will call inner with the right parameters. Static
chaining also requires a trampoline in this case, but the trampoline
is always essentially identical in all cases (load the static chain
pointer, call the function). With lambda lifting the trampoline can
be arbitrarily complex.




> My next doubt is regarding the nested function support from GCC using
> trampolines. I could see that in case of function pointers of nested
> functions GCC was generating the code on the stack to move the frame
> pointer of the function in which the nested function is nested to ECX
> and then to do a jump to the nested function.
>
>
> My question is
> Whether GCCs support for nested functions is similar to nested function
> support in functional languages like haskell/scheme and do trampolines
> provide any advantage other than access time.?
>
> I realise that you cannot return a nested func pointer and pass it
> around since theres no way GCC associates state with the ptr.


Languages with full closures and continuations, like Scheme, require
extra work. You need to capture, in principle, the entire stack. So,
no, they are not particularly similar. gcc's support for nested
functions is much simpler, and does not support closures--it does not
solve the upward funarg problem.


Ian


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.