Re: nested functions

Marco van de Voort <marcov@stack.nl>
6 Sep 2006 17:19:03 -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)
Re: nested functions Jatin_Bhateja@mentor.com (Jatin Bhateja) (2006-09-08)
Re: nested functions 148f3wg02@sneakemail.com (Karsten Nyblad) (2006-09-08)
Re: nested functions foobar@nowhere.void (Tommy Thorn) (2006-09-08)
Re: nested functions torbenm@app-3.diku.dk (2006-09-08)
Re: nested functions chris.dollin@hp.com (Chris Dollin) (2006-09-08)
| List of all articles for this month |

From: Marco van de Voort <marcov@stack.nl>
Newsgroups: comp.compilers
Date: 6 Sep 2006 17:19:03 -0400
Organization: Stack Usenet News Service
References: 06-08-140 06-08-144
Keywords: code, design

On 2006-08-30, Tommy Thorn <tommy.thorn@gmail.com> wrote:
> > I realise that you cannot return a nested func pointer and pass it
> > around since theres no way GCC associates state with the ptr.
>
> Exactly! Trampolines are a sad compromise to implement closure-like
> structures in a way that can co-exist with ordinary C (which expects
> function pointers to point to code, not data structures). For language
> implementations with direct support for closures, it's generally
> better to use a structure with free variables and a function pointer
> (very much like a C++ object and one virtual function).
>
> There are exceptions to this which are hard to classify. Check
> "Optimization for Lazy Functional Languages" by Urban Boquist for a
> really all-out approach (and google "jhc haskell").


IIRC GPC (Gnu Pascal compiler) uses trampolines too. I can't remember
the exact details, but afaik the main reason had to do with passing
nested procs to other procedures. Some code to explain:


procedure xxx(proctype : someproctype);


begin
  proctype; // can access sharedstate
end;


procedure outer;


var sharedstate : integer;


procedure inner;


begin
    sharedstate:=sharedstate+1; // r/w
end;


begin
    xxx(inner);
end;


procedure otherproc;


begin
    xxx(outer);
end;


I believe they used trampolines to make sure the call chains were valid both
when passing inner and outer (top level) procs.


Some simple gpc -S 'ing might reveal some more info. (probably there are
other ways too, but gcc probably already supported trampolines)



Post a followup to this message

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