Stack Usage in CCS3

This morning I discovered something that was unexpected and I am hoping
that someone with more knowledge of Code Composer can help me make more
sense of it.

I am in the beginning stages of constructing an application that uses
TI's dsp/BIOS.  One of the routines makes a function call to another
routine that displays a message on my 4x20 character display.  The
routine that calls the message display function passes the starting
character location, the size of the message and a pointer to the first
character to be displayed.

At first, I was building the project and linking to RAM memory to avoid
having to erase and reprogram the flash during debug.  The problem I
ran into is that it appears that CCS pushes the entire message onto the
stack rather than passing an address.  I say appears based on an
aalysis of the MAP file and the dis-assembly listing (I am still
admittedly a bit of a novice at reading TI's assembly) - where the
assembly listing shows an allocation of stack space proportional to the
message length. Of course this resulted in a stack overflow and a
subsequent program crash.  This occurs even when the message string is
declared as a CONST type.  It doesn't appear to matter if the text
string is declared globally or locally.

Later, I re-linked the project and compiled the same code into flash.
A review of the stack usage shows that it decreased by half and the
paramater is apparently passed as a pointer to the flash memory
location.

At the moment, I am having a bit of trouble understanding why the
message would be pushed onto the stack as apposed to the address when I
am passing a pointer as a paramater.  Part of what doesn't make sense
is that the compiler should be oblivious to the fact that the code is
going into flash as opposed to ram, so I fail to understand why I am
getting a different result.  Has anyone encountered this before?

>This morning I discovered something that was unexpected and I am hoping
>that someone with more knowledge of Code Composer can help me make more
>sense of it.
>
>I am in the beginning stages of constructing an application that uses
>TI's dsp/BIOS.  One of the routines makes a function call to another
>routine that displays a message on my 4x20 character display.  The
>routine that calls the message display function passes the starting
>character location, the size of the message and a pointer to the first
>character to be displayed.
>
>At first, I was building the project and linking to RAM memory to avoid
>having to erase and reprogram the flash during debug.  The problem I
>ran into is that it appears that CCS pushes the entire message onto the
>stack rather than passing an address.  I say appears based on an
>aalysis of the MAP file and the dis-assembly listing (I am still
>admittedly a bit of a novice at reading TI's assembly) - where the
>assembly listing shows an allocation of stack space proportional to the
>message length. Of course this resulted in a stack overflow and a
>subsequent program crash.  This occurs even when the message string is
>declared as a CONST type.  It doesn't appear to matter if the text
>string is declared globally or locally.
>
>Later, I re-linked the project and compiled the same code into flash.
>A review of the stack usage shows that it decreased by half and the
>paramater is apparently passed as a pointer to the flash memory
>location.
>
>At the moment, I am having a bit of trouble understanding why the
>message would be pushed onto the stack as apposed to the address when I
>am passing a pointer as a paramater.  Part of what doesn't make sense
>is that the compiler should be oblivious to the fact that the code is
>going into flash as opposed to ram, so I fail to understand why I am
>getting a different result.  Has anyone encountered this before?

You could mention which ISA you are talking about. My familiarity is with
C6000 and its code generation.Since you mention about Code Composer as
opposed to Code Composer Studio I am inclined to think that you are
refering to C2000 series DSP's as opposed to C6000. C2000 is is not a DSP
that I have programmed much.

Even if I assume it is C6000 that you are referring to, I dont know if I
fully understand the problem. I might though offer this hint:

There is a C6000 C code-> assembly interface standard. This is *always*
obeyed by the compiler. The codegen allows you to send upto 10 parameters
in place:

First argument  : A4 register  
Second  argument: B4 register
Third  arguments: A6 register
Fourth arguments: B6 register
Fifth arguments : A8 register
sixth arguments : B8 register
seventh argument: A10 register
eight  argument : B10 register
ninth  arguments: A12 register
tenth arguments : B12 register 

Are you passing more?

--Bhooshan

		
This message was sent using the Comp.DSP web interface on
www.DSPRelated.com

On 10 Oct 2005 10:38:38 -0700, "Noway2" <no_spam_me2@hotmail.com>
wrote in comp.dsp:

> This morning I discovered something that was unexpected and I am hoping
> that someone with more knowledge of Code Composer can help me make more
> sense of it.
> 
> I am in the beginning stages of constructing an application that uses
> TI's dsp/BIOS.  One of the routines makes a function call to another
> routine that displays a message on my 4x20 character display.  The
> routine that calls the message display function passes the starting
> character location, the size of the message and a pointer to the first
> character to be displayed.
> 
> At first, I was building the project and linking to RAM memory to avoid
> having to erase and reprogram the flash during debug.  The problem I
> ran into is that it appears that CCS pushes the entire message onto the
> stack rather than passing an address.  I say appears based on an
> aalysis of the MAP file and the dis-assembly listing (I am still
> admittedly a bit of a novice at reading TI's assembly) - where the
> assembly listing shows an allocation of stack space proportional to the
> message length. Of course this resulted in a stack overflow and a
> subsequent program crash.  This occurs even when the message string is
> declared as a CONST type.  It doesn't appear to matter if the text
> string is declared globally or locally.
> 
> Later, I re-linked the project and compiled the same code into flash.
> A review of the stack usage shows that it decreased by half and the
> paramater is apparently passed as a pointer to the flash memory
> location.
> 
> At the moment, I am having a bit of trouble understanding why the
> message would be pushed onto the stack as apposed to the address when I
> am passing a pointer as a paramater.  Part of what doesn't make sense
> is that the compiler should be oblivious to the fact that the code is
> going into flash as opposed to ram, so I fail to understand why I am
> getting a different result.  Has anyone encountered this before?

What DSP?  Show the C code for the function prototypes, the data
definitions, and the function call.

-- 
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~ajo/docs/FAQ-acllc.html

Thank you both for the replies.  As an update, it appears that I may
have been partially mistaken in my information.  It looks as though
when the message is declared globally that it may be passed as an
address parameter and not as an entire message, as indicated by the
stack used (reported by the bios debug utilities).  It occured to me
this morning, that what is probably happening is that the stack usage
comes from allocating space for the locally declared variable, rather
than pushing of the message directly.  The called routine then accesses
this memory, which is also in the vicinity of the stack pointer and it
appears that the message is being passed on the stack.


In either case, since it was asked for, the project does use a c2000
version, an F2812 to be exact.  The function call and prototypes are as
follows:

Prototype:
void displayMessage(int startchar, int numchar, const char *Datastr);

Message (test message):
const char message[ ] = "The Quick Brown Fox Jumped Over The Lazy Dog's
Back 0123456789\0";

Function call:
displayMessage(0, strlen(message), message);

While my experience with TI processors and with their BIOS / RTOS grows
daily during this adventure, it is still limited.  It was the stack
overflow and subsequent lock in a "bios self loop trap function" that
threw me off.  I am used to the custom control loop implementation,
where the stack grows down through all of the free memory, rather than
having to specifically allocate X number of bytes of stack for a
particular task or routine, which added to my confusion.

I am thinking at this moment, that the issue may be dead (having likely
explained the stack issue(s) to myself), but I do appreciate your help!