Thread: How to calculate the Stack Size?

Originally Posted by Elysia

And this is why it cannot be guaranteed to work or work properly, and so should be avoided IMHO.

Ok, so how do you solve the problem I just described - you have an embedded system that has a realistic, but strict stack-limit [with a currently known processor architecture that uses a stack].

I do understand that this forum is supposed to solve things in a portable and generic way, but does that mean that EVERY time someone posts something that, on some obscure machine that three people on this forum have ever heard of, it must be said as "unportable and unreliable", even when it actually solves the original posters problem.

Can you point out where in my original code I am not solving the original posters problem?

[and by that, I do not mean to solve the analyze the source code and find out by that how much stack it uses, because that would require a few thousand more lines of code].

--
Mats

Originally Posted by matsp

If you mean that "no code should rely on KNOWING the size of the stack", then I would agree - but you then have to assume that it is big enough for what you want to do. And in an embedded system, the stack may well be in the kilobytes rather than megabytes range.

That is a better term to describe it, yes.

Originally Posted by matsp

Ok, so how do you solve the problem I just described - you have an embedded system that has a realistic, but strict stack-limit [with a currently known processor architecture that uses a stack].

I do understand that this forum is supposed to solve things in a portable and generic way, but does that mean that EVERY time someone posts something that, on some obscure machine that three people on this forum have ever heard of, it must be said as "unportable and unreliable", even when it actually solves the original posters problem.

I don't know. But again, I don't see code that relies on knowing the stack size to be good code.
I can very well understand that there are tricky systems out there, and they may require special methods for solving the problems, but at this point, I cannot see any good knowledge of knowing the stack size.
If stack size is limited, limit recursion to a few nested calls instead of trying to know the stack size.

Can you point out where in my original code I am not solving the original posters problem?

[and by that, I do not mean to solve the analyze the source code and find out by that how much stack it uses, because that would require a few thousand more lines of code].

I'm sorry, but no, because I don't understand the code and I haven't taken the time to understand it because it doesn't really interest me.
I don't doubt your code would work (it probably does work), but I don't want to call it reliable.

Yes, you can work to reduce stack size usage - and the defining criteria for HOW much such work you need depends on how far from the limit you are [and whether you can trivially just ask for more stack, or if that leads to reducing some other memory area, which leads to extra work elsewhere that requires even more effort]. It is exactly like any other optimization work - unless you have some sort of "benchmark", how do you determine when you should optimize (in this case, reduce the stack usage).

I am also not suggesting that you sprinkle the size of the stack all over the place in the code, or any such thing. Ideally, it should ask the OS about how large the stack is that it's been given. My code doesn't do that - I use a hard-coded value.

I do understand that you have never worked in a system where you do not have a "within reason unlimited" stack.

The concept for my stack usage checker that I posted comes from a RTOS I used to work with many years ago. It had a fill-pattern for the stack that was filled when the process is created (you need to fill the stack with something anyways, otherwise you may get data leakage from one process to another), and it had utility programs to discover how much was remaining of that fill pattern. Of course, this also means that you don't have to write your own code to find out. But I'm presuming the original poster is actually not fortunate to have tools that do this.

--
Mats