|[Q:] tail calls and parameter passing firstname.lastname@example.org (Fermin Reig) (1998-11-19)|
|Re: [Q:] tail calls and parameter passing email@example.com (1998-11-21)|
|Re: [Q:] tail calls and parameter passing firstname.lastname@example.org (John D. Ramsdell) (1998-11-21)|
|Re: [Q:] tail calls and parameter passing email@example.com (Stefan Monnier) (1998-11-24)|
|Re: [Q:] tail calls and parameter passing firstname.lastname@example.org (Biju Thomas) (1998-11-24)|
|From:||Biju Thomas <email@example.com>|
|Date:||24 Nov 1998 22:22:38 -0500|
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
Return to the
Search the comp.compilers archives again.