`arhodes19044 wrote:`

> I used BxDism, and confirmed that I was running out of stack space in

> a major way. I deleted wasted space/variables and fised it up and

> have just enough by 5 bytes, according to BxDism. This is tight

> enough that I am worried. None of my functions are very odd, so all

> the required stack should be pretty obvious in static analysis. With

> only 5 to spare, I will soon find out.

>

> One question, the total stack required that BxDism lists, Does this

> equal the worse case of the stack required for the entire function

> tree (Functions called by functions which are called by yet another

> function, and so on)? I would presume it is. I have a few stack

> hungry functions. Of course, they are string processing functions.

>

It is a static analysis of the worst case including nested functions and

the expression calculations within a function/subroutine. However

because strings are managed dynamically it turns out that the RAM

calculation when strings are involved is the most difficult to get

right. For simple functions the amount of RAM used grows to some maximum

and shrinks back to zero at the end of function. However for strings

manipulation I sometimes did not get back to zero because of the dynamic

stack manipulations for strings. So the answer is more complete than

RAMAnalyzer but is still not perfect. Only running your application will

determine the real answer.

Everything else Don said is correct. Flattening your call hierarchy and

careful ordering of expression calculations can save stack space.

Mike

> I used BxDism, and confirmed that I was running out of stack space in

> a major way. I deleted wasted space/variables and fised it up and

> have just enough by 5 bytes, according to BxDism. This is tight

> enough that I am worried. None of my functions are very odd, so all

> the required stack should be pretty obvious in static analysis. With

> only 5 to spare, I will soon find out.

>

> One question, the total stack required that BxDism lists, Does this

> equal the worse case of the stack required for the entire function

> tree (Functions called by functions which are called by yet another

> function, and so on)? I would presume it is. I have a few stack

> hungry functions. Of course, they are string processing functions.

>

It is a static analysis of the worst case including nested functions and

the expression calculations within a function/subroutine. However

because strings are managed dynamically it turns out that the RAM

calculation when strings are involved is the most difficult to get

right. For simple functions the amount of RAM used grows to some maximum

and shrinks back to zero at the end of function. However for strings

manipulation I sometimes did not get back to zero because of the dynamic

stack manipulations for strings. So the answer is more complete than

RAMAnalyzer but is still not perfect. Only running your application will

determine the real answer.

Everything else Don said is correct. Flattening your call hierarchy and

careful ordering of expression calculations can save stack space.

Mike