CODEWITHSUNDEEP
cembedded
user2568508
user2568508

Reputation:

Possible stack size of embedded device

I am programming some embedded device which has 64 MB SDRAM. (C is used as programming language). Is it possible to make a guess (maybe even a rough guess) about the possible size of the stack of this device? Referring to memory which gets used when we make allocations such as, e.g.,

char s[100];
int t[50];

etc.

e.g., will it be more than 50KB? etc. that is what I mean with rough

plus when I have variables inside some function f

f()
{
  int p;
}

when f() exists, this variable dies right?

So when I call f2():

void f2()
{
  char t[100];
}

Only the size of a 100 element char array will be added to the stack size right?? size of int p from previous function is not considered anymore.

Upvotes: 1

Views: 2737

Answers (4)

Clifford
Clifford

Reputation: 93476

You may find that your linker is capable of performing stack requirement analysis - normally by command line option to specify map file content. If you could add information about your toolchain, you will get better advice.

What such analysis gives you is the worst case stack usage and the call path involved for any particular function - for the process total you need to look at the stack usage for main() and any other thread entry points (each of which will have a separate stack). You may need also to consider ISRs which on some targets may use the interrupted process or thread stack, on others there may be a separate interrupt stack.

What linker stack analysis cannot determine is stack usage in the case of recursion or call through function pointers, both of which depend on the prevailing runtime conditions that cannot be determined statically.

Upvotes: 0

Christophe Vu-Brugier
Christophe Vu-Brugier

Reputation: 2731

There is a script in the Linux kernel sources that can help you find the functions that heavily allocate on the stack. The script is named checkstack.pl and is located in the scripts directory.

Here is a sample invocation:

$ objdump -d $BUILDDIR/target-isns | perl checkstack.pl x86_64
0x00403799 configfs_handle_events []:                   4384
0x004041d6 isns_attr_query []:                          4176
0x00404646 isns_target_register []:                     4176

The script displays the functions that consumes the most space on the stack. The script can help you make a guess for the stack size required. Also, it helps you determine which functions should be optimized with regard to their stack usage.

Upvotes: 0

kakeh
kakeh

Reputation: 403

your question looks like ,"Guessing the stack size"

Why guess when you can know it exactly its not from the sky ! :)

For an embedded programmer the stack size is always his in hands,one has to handle it through the linker command file that he submit to a loader

some thing like this as below

Linker.cmd

MEMORY
{

 .
 .
    SARAM2  (RWIX) : origin = 0x039000, length = 0x010000 /*64KB*/  
 .
 .    
 }

 SECTIONS
 {
 .
 .
   .stack     > SARAM2 
   .sysstack  > SARAM2 
 .
 .
 }

so its clear that you can set your own stack size provided "the stack size is limited to stack pointer bound"

so it is completely depends on your stack pointer range, if your stack pointer is 16bit you stack size is limited to 2^16 which is 64KB

for instance moving away from firmware programming, in a standard linux machine also if you go for typing 

ulimit -a

you will get your limited stack size,and its extendable up to the boundary where Stack Pointer can point to

BTW These may further help you

Direction of Stack Growth

When Does Stack Really Over Flow

and i also suggest its not a bad idea to monitor your stack size , in other words trying to find Stack pointer value which can make you clear 'what is your stack status ?', especially for an embedded programmer a stack overflow cause severe damage :)

Upvotes: 1

Throwback1986
Throwback1986

Reputation: 6005

All sorts of guesses can be made :) Most (all?) embedded development environments provide mechanisms for allocating device memories (read-only, stack, heap, etc.) This is commonly done through linker directive files or C #pragmas placed in a setup source file. Without more information on your development environment, no accurate guess can be made.

In function f(), variable p will exist on the stack. When the function exits, that location on the stack will likely be used for something else.

As for function f2(), you can expect that 100 bytes from the stack will be assigned to t while this function is executing. The size of p will not be considered.

Note that the stack can be used for other information, so you cannot reliably estimate stack usage without considering other factors. For example, do you expect recursion? The stack can be used to store function call/return information - thereby reducing the amount of space you have for local (stack) variables.

Lastly, I've worked with devices operating with less than 1KB of stack, so assumptions should be made carefully.

Upvotes: 5

Related Questions