Re: nested functions (=?iso-8859-1?q?Torben_=C6gidius_Mogensen?=)
30 Aug 2006 14:12:36 -0400

          From comp.compilers

Related articles
nested functions (2006-08-29)
Re: nested functions (Tommy Thorn) (2006-08-30)
Re: nested functions (Ian Lance Taylor) (2006-08-30)
Re: nested functions (2006-08-30)
Re: nested functions (Tommy Thorn) (2006-08-30)
Re: nested functions (2006-08-31)
Re: nested functions (Tommy Thorn) (2006-08-31)
Re: nested functions (Marco van de Voort) (2006-09-06)
Re: nested functions (Tommy Thorn) (2006-09-06)
Re: nested functions (Jatin Bhateja) (2006-09-08)
[4 later articles]
| List of all articles for this month |

From: (=?iso-8859-1?q?Torben_=C6gidius_Mogensen?=)
Newsgroups: comp.compilers
Date: 30 Aug 2006 14:12:36 -0400
Organization: Department of Computer Science, University of Copenhagen
References: 06-08-140
Keywords: code, design
Posted-Date: 30 Aug 2006 14:12:36 EDT writes:

> I have a doubt regarding the nested functions and how the same is
> supported in languages. I don't have much knowledge in compilers
> except for the occasional reading.
> Please correct me if my understanding is wrong.
> 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?.

Lambda lifting using an environment pointer is equivalent to static
chaining, the main difference is that lambda lifting is done at
source-language level whereas chaining is done at object-language
level. Not all source languages are flexible enough to make lambda
lifting feasible, though, so sometimes it is done at an intermediate
language level.

Chaining is essentially an "unfolded" form of chaining, where you keep
the entire chain as an array in each frame instead of as a linked list
that crosses frames. As such, the main issue here is performance:
Displays make frames larger and more costly to create, but they speed
up access to non-local variables a bit. You can, however, get most of
the benefit of that by caching the pointers to outer frames in
registers after their first use.

I don't know the internals of GCC, so I can't answer your questions
regarding that.


Post a followup to this message

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