Actually, that's not what I meant.
GCC optimization levels
The optimizer doesn't really know how to generate fast code. It can optimize for size, algorithmic complexity, combine constants, and move constant expressions out of loops, inlining. You get the idea. These things will typically generate fast code, but this is not guaranteed. Also, GCC has no way of counting cycles or taking advantage of the speed of the scratchpad memory.
You have access to the optimization settings and if it were beneficial, you could use faster or smaller stack code generation based on those settings.
I think it's safe to say you'd want the registers in scratchpad memory by default. The C stack is usually too large for that so you could only place it there for small programs. Since most variables are in the stack area it could make a significant speed difference.
Scratch pad memory usage
I'm not familiar with the TI memory map but I *suppose* if scratchpad memory were part of a larger contiguous block of RAM you could put the registers at the top of scratchpad mem and the stack right below them. If the size of the stack exceeded scratchpad it could grow down into regular RAM. However, the inner loops where the stack is greatest usually need the most speed so that might not add up to the fastest executable.
If you knew the maximum size of the stack, you could place the stack where it would grow down into scratchpad memory for inner loops just as long as you couldn't overwrite your registers at the bottom of the scratchpad area. This would be set up by the startup code and would be application specific. I think using scratchpad in one of those manners makes much more sense than allocating it through a call.
Keep in mind if you use global or static variables for a lot of things like temporary values or commonly used structures, you could conserve scratchpad memory and improve the performance of your application.
Edited by JamesD, Wed Jun 23, 2010 3:59 PM.