|inling/tail recursion, recursive decent parser firstname.lastname@example.org (Lefteris Keftedopoulos) (2005-06-21)|
|Re: inling/tail recursion, recursive decent parser email@example.com (2005-06-23)|
|Re: inling/tail recursion, recursive decent parser firstname.lastname@example.org (2005-06-30)|
|Re: inling/tail recursion, recursive decent parser email@example.com (Ronny Wichers Schreur) (2005-07-02)|
|Re: inling/tail recursion, recursive decent parser cfc@shell01.TheWorld.com (Chris F Clark) (2005-07-02)|
|From:||firstname.lastname@example.org (Henry Spencer)|
|Date:||23 Jun 2005 22:03:25 -0400|
|Organization:||SP Systems, Toronto, Canada|
|Posted-Date:||23 Jun 2005 22:03:25 EDT|
Lefteris Keftedopoulos <email@example.com> wrote:
>Would inlining / tail recursion have significant effect on the amount
>of call stack space used by a recursive decent parser?
Tail recursion unfortunately isn't common in recursive-descent parsers.
Much more usual are structures like:
while (there's more)
which unfortunately don't lend themselves to that kind of optimization.
Inlining could help substantially, if you're willing to accept some
increase in code size. In a straightforward recursive-descent parser,
many procedures are called from only one or two places. Inlining
won't reduce the space used for variables very much, but it will cut
out a lot of per-call stack-frame overhead. (Caveat: the benefits
will be reduced substantially if operator precedence in expressions is
handled by some specialized trick rather than by having a level of
procedures per level of precedence.)
"Think outside the box -- the box isn't our friend." | Henry Spencer
-- George Herbert | firstname.lastname@example.org
Return to the
Search the comp.compilers archives again.