Re: BxDism question Re: stack

Started by Mike Perks August 7, 2005
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 wonder if it might be possible to give a worst case estimate of
the stack space required by a string. I finally found the sentence
in the docs regarding string allocation.

It says: "A variable length string always requires a constant
storage, which is 2 bytes plus the user-defined maximum."

Probably 99% of all string usage is variable length strings (I bet
fixed and bounded usage is quite unusual), and probably nobody
bothers to reduce the user-defined maximum. Therefore a worst-case
estimate of string-based stack usage is probably correct 99% of the
time when it is estimated at 66 bytes, and can never be worse than
that.

Since this seems pretty obvious, I am sure Don and you already
thought of that. Since you find that you can not be sure of stack
usage with strings, there must be something more complex here which
I am missing.

-Tony

--- In basicx@basi..., Mike Perks <basicx@a...> wrote:
> 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