- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The Nios II Software Developer's handbook states:
stack checking has performance costs. if you choose to leave stack checking turned off, you must code your program so as to ensure that it operates within the limits of available heap and stack memory. Is there a way to initialize a memory area (i.e. the heap and/or stack) to a known value so that level testing/profiling can be performed? I want to know how much of this memory my program uses in practice. Thanks, -BradLink Copied
2 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
--- Quote Start --- The Nios II Software Developer's handbook states: stack checking has performance costs. if you choose to leave stack checking turned off, you must code your program so as to ensure that it operates within the limits of available heap and stack memory. Is there a way to initialize a memory area (i.e. the heap and/or stack) to a known value so that level testing/profiling can be performed? I want to know how much of this memory my program uses in practice. Thanks, -Brad --- Quote End --- If you are using uCOS-II, you can initialize the stacks before you setup the tasks. For example, in one design, I initialize task 1's stack to 0x11111111, task 2's to 0x22222222, etc., before I start the OS. If you are not using an OS, then you can use C code to just fill the locations before them, or you can use linker sections, and linker fill values, eg., put each stack in their own section and give them names, and then use those names in the C-code ... but that is compiler dependent ... I forget how gcc does it. Generally its much easier for others to understand your code if you do all this in C code during initialization. Cheers, Dave
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
An issue worth remembering is that the maximum stack use is likely to be in an error path somewhere - possibly inside printf() or the logging functions. So looking at what has been written to the stack area isn't necessarily that useful.
For code that has no recursive or indirect calls and doesn't use alloca() it is possible to do a static analysis since compiler generated code (and most hand assembler) will have a fixed stack size/offset for each function and call site. Parse the compiler asm listing (gcc -S -fverbose-asm ...) or a disassembly of a fully fixed up progam image.
Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page