|Caclulating operand stack size email@example.com (2005-05-14)|
|Re: Caclulating operand stack size firstname.lastname@example.org (2005-05-16)|
|Re: Caclulating operand stack size email@example.com (Aaron Gray) (2005-05-16)|
|Re: Caclulating operand stack size DrDiettrich@compuserve.de (Hans-Peter Diettrich) (2005-05-18)|
|Re: Caclulating operand stack size firstname.lastname@example.org (2005-05-18)|
|From:||email@example.com (Anton Ertl)|
|Date:||18 May 2005 12:04:54 -0400|
|Organization:||Institut fuer Computersprachen, Technische Universitaet Wien|
|References:||05-05-105 05-05-136 05-05-158|
|Posted-Date:||18 May 2005 12:04:54 EDT|
Hans-Peter Diettrich <DrDiettrich@compuserve.de> writes:
>Anton Ertl wrote:
>> You can even calculate the depth including any non-recursive direct
>> calls from the current function, and check for that, so you don't need
>> to check at every such call. You have to arrange the calling
>> convention appropriately; I would do it like this: the caller is
>> responsible for the checking and growing, and (for indirect calls)
>> accesses a field in the callee that contains information about the
>> maximum stack depth of the callee before the next check.
>You realize that your approach will have to separate subroutines, that
>do the stack check, from subroutines that do not have to perform stack
Probably not in the way that you are thinking of.
Yes, subroutines that perform indirect or recursive calls have to
check (when they call, not when they are entered), and subroutines
that don't, don't.
No, we don't have to create two instances of subroutines, one with
checking, and one without.
That's why I have the caller perform the check-and-grow, not the
callee: the callee does not know how it is called (and this will
actually be different); the caller knows how it calls.
>How many subroutines can be allowed to omit an stack check, in every
Arbitrarily many. However, you might want to limit the amount of
stack that is reserved, and perform the check-and-grow for some direct
non-recursive calls if they would add too much to the maximum stack
M. Anton Ertl
Return to the
Search the comp.compilers archives again.