Re: stack overflow at compile time

glen herrmannsfeldt <gah@ugcs.caltech.edu>
3 May 2006 20:02:05 -0400

          From comp.compilers

Related articles
[8 earlier articles]
Re: stack overflow at compile time emailamit@gmail.com (Amit Gupta) (2006-04-29)
Re: stack overflow at compile time bobduff@shell01.TheWorld.com (Robert A Duff) (2006-04-29)
Re: stack overflow at compile time emailamit@gmail.com (Amit Gupta) (2006-04-30)
Re: stack overflow at compile time henry@spsystems.net (2006-04-30)
Re: stack overflow at compile time henry@spsystems.net (2006-04-30)
Re: stack overflow at compile time bobduff@shell01.TheWorld.com (Robert A Duff) (2006-05-01)
Re: stack overflow at compile time gah@ugcs.caltech.edu (glen herrmannsfeldt) (2006-05-03)
| List of all articles for this month |

From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Newsgroups: comp.compilers
Date: 3 May 2006 20:02:05 -0400
Organization: Compilers Central
References: 06-04-157 06-04-161 06-04-166 06-04-177 06-04-178
Keywords: storage, analysis

(John wrote)


> [It's not even the size of the address space. If my frame size is,
> say, a megabyte, and my recursion is a million, I'm going to need a
> million megabytes. If the system doesn't have a million megabytes,
> well, shucks, my program will fail. I entirely agree that in many
> useful special cases you can do static stack size analysis and come up
> with a result, but in the general case, it's hopeless. -John]


Well, you could use stack of stacks like JVM does, with a new stack for
each call.


But I would say the previous post is right: You are limited by the
address space in the sense that you can't physically recurse any deeper.


I still remember when the 8080 came out advertising 65536 levels of
calls, not including the fact that the return address takes two bytes,
and you might want some space for code and data.


-- glen


Post a followup to this message

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