Setting stack pointer

TINewbie,

In general, it's a very bad idea to do inline assembly.  If you are going to take this type of approach, you should implement it as a full assembly language function, not as a C function with inline assembly calls.  When you put a asm(" "); statement in your C code, the compiler just pastes in the ASM instruction wherever that asm(" "); statement appears. In the best case, this places an optimization barrier in your code, so you might consume more cycles than necessary.  In the worst case, it will get moved by the optimizer to a location that is slightly different than where you think it should go.  This can be catastrophic.

With that being said, let's try to avoid assembly language altogether, if we can.  Let me make sure I fully  understand your use case. As I understand it, you're responsible for a function in a larger application.  The top level application calls you at certain times, but you don't know how much memory will be available on the system stack when you are executed, so you have your own memory that you want your code, and the stuff it calls to be able to use as stack.  Please let me know if I have misunderstood this, so far.  Here are some follow-up questions:

• Doesn't the overall system have to have some max limit of stack space it uses, otherwise, it crashes?  I'm just curious about what the advantages are of segmenting your memory in this way. For example,  Say the top level application has allocated 4 K of memory for it's stack, and you have 1 K for your function .  (The actual values may be much larger or much smaller, I'm just using these as an example.)  This means that the max stack usage by the to level application never exceeds 4K.  So, why not just tell the top level application to allocate 5K of memory for the stack?  The top level app still won't exceed using 4K, which means, in the worst case, your function would have at least 1K of stack space left when it executes. You may have a valid reason for doing it this way.  Maybe these different stack sections have different memory characteristics.  I'm just trying to be sure I understand the overall view.
• There will be issues with debugging this code, if you ever have to.  The call stack won't work, because it uses SP relative access to determine the calls on the stack.  If your stack is segmented in this way, there's no way for the debugger to resolve the entire call stack.
• Is this a multithreaded application?  If so, how do the threads use the stack?  I'm worried about a case where your code is entered, and the stack pointer is moved, and then a thread switch occurs without the stack pointer being set back to whatever the new thread expects it to be.

In response to your question about how to read variables from assembly, it somewhat depends on the type of variables. For a global variable, in an assembly file, you can just use the .global identifier.  Local variables are stored on the stack, so you have to know the offset of from the stack pointer to the variable.  If the values are function parameters, their location is determined by the Register Argument conventions.  All of these are discussed in the C6000 Compiler Guide.  See the links below.

Here are a few links:

C6000 Compiler Guide: http://www.ti.com/litv/pdf/spru187t

C6000 Assembly Language Tools User's Guide http://www.ti.com/litv/pdf/spru186v

Regards,
Dan

Just one additional comment about your statement  "However, I would guess that all registers are preserved at a context switch, no? I know that may be more of a question for the top level app people..."

I think that a multi-threaded application probably uses separate "stacks" for each thread, and the registers are preserved on each.  The "stacks" that I am referring to are different than the one that we are discussing.  Now that I think about it, what you are asking about doing is similar to what an OS would do when it switches contexts.  It would likely save the context on a stack, and then in the context switch, change the stack pointer to pint to the stack for the next thread, and then restore the register context that is stored there.  So, it sounds reasonable to do what you are wanting to do. 

Regards,

Dan