Related articles |
---|
[Q:] tail calls and parameter passing reig@dcs.gla.ac.uk (Fermin Reig) (1998-11-19) |
Re: [Q:] tail calls and parameter passing gary@wheel.tiac.net (1998-11-21) |
Re: [Q:] tail calls and parameter passing ramsdell@linus.mitre.org (John D. Ramsdell) (1998-11-21) |
Re: [Q:] tail calls and parameter passing monnier+comp/compilers/news/@tequila.cs.yale.edu (Stefan Monnier) (1998-11-24) |
Re: [Q:] tail calls and parameter passing bijuthom@ibm.net (Biju Thomas) (1998-11-24) |
From: | Biju Thomas <bijuthom@ibm.net> |
Newsgroups: | comp.compilers |
Date: | 24 Nov 1998 22:22:38 -0500 |
Organization: | Compilers Central |
References: | 98-11-090 |
Keywords: | code, optimize |
Fermin Reig wrote:
> I would appreciate pointers to papers that describe implementations of
> tail call optimization in languages that implement activation frames
> in the stack.
>
If you haven't come across this book yet, Muchnick's 'Advanced Compiler
Design & Implementation' has a section on tail-call optimization
(chapter 15). It touches upon the issues that you bring up here, but not
in very much detail nor with any bibliography.
> [how to do a tail call from a routine without memory parameters to
> a routine with them ]
>
> The tail call sequence can be as large as one wants: G -> H -> ... and
> one of these procedures may expect any number of arguments in the
> stack (in the caller's frame).
AFAIK, the caller need to extend the stack frame by the difference in
the sizes of the stack frames of the two procedures.
> Moreover, F can be in a different module from G, H ..., so when we
> compile F we may know how many memory arguments G expects (none), but
> we have no way of knowing that G will make the tail call.
The compiler should store the information about the parameters of G in
its internal interface specification, and, hold onto it till the
optimization phase.
Regards,
Biju Thomas
Return to the
comp.compilers page.
Search the
comp.compilers archives again.