Ok, I missed this _little_ difference. It makes of course no sense at all to calculate the stacksize (or e.g. heap usage) from the source alone w/o the environment parameters that are compiler, optimizing level, target and eventually the used (RT)OS.
But I think there are now some very sophisticated tools arround (Coverty comes to mind) which can do such, but need some input vectors.
-- 42Bastian Do not email to bastian42@yahoo.com, it's a spam-only account :-) Use @monlynx.de instead !
Solution 1: if you don't know what your compiler will generate from your source, you simply look what it does generate. Actually, scanning the assembler output for 'sub sp,NN', 'link', 'enter' instructions is much easier than parsing C and looking for local variables. Compilers tend to use only a few forms of procedure prologues, easy to match with a few regexes.
Solution 2: if you want to work an C code, just overallocate. Pretend register variables don't exist. Assume one register spill per operand.
Exactly. That's why an educated guess based on C code may very well work.
However, especially when you're not working alone on a project, it will be useful to have some mechanism to verify your assumptions still hold. Your thread ran fine with 512 bytes of stack when you wrote it, but you should verify that Joe R. Hacker did not add a routine with a 1K buffer at a rarely-used place in the middle of the call tree before ordering the ROM mask.
Stefan
...
That won't give a safe estimate for SPARC code, where compilers must allocate space in each stack frame for dumping one register window (over
100 octets) even for almost null subprograms, the only exception being leaf subprograms that may avoid this.But is it enough that it "may" work? If it doesn't work, stack overflow may cause very peculiar bugs later on.
I would accept source-code-based estimates on stack usage only in early design phases, for estimating the memory required for stacks as part of sizing the platform, and only after calibrating the estimation procedure against some real code on the chosen compiler and processor. That is close to what Grant Edwards wrote.
--
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
. @ .
Also, if you are the author of a program and know the limitations of the analysis tool, you may well be able to arrange the program to be "well-written".
-- Pertti
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.