CCS issues to watch local variables

Thank you so much for the suggestions.

I think I can adjust the stack size. However, even though, during the debug mode, I still could not get the local variables value in the called function.

I really have no other solutions....

----- Original Message -----
From: William C Bonner
To: r...@gmail.com
Cc: c...
Sent: Thursday, June 18, 2009 1:19 PM
Subject: Re: [c6x] Re: CCS issues to watch local variables
I'm using a linker command file to specify the memory sections in my project. one of the lines I've got is:

-stack 0x3C00

which specifies how much space the stack should get allocated.

On my release code, I also tell the environment that I want it to generate a map file so that I can see where all of the global symbols got located. Looking in the map file I can find this section of output:

.stack 0 00028800 00003c00 UNINITIALIZED
00028800 00000008 rts6700.lib : boot.obj (.stack)

Which tells me that 0x3c00 was actually allocated, starting at address 0x28800. Also, something from the library gets put in the first 8 bytes of the stack space. I don't know what it is, and am just assuming that it's a necessary part of the platform code. Since it's only 8 bytes, I'm not overly concerned about the space.
On Thu, Jun 18, 2009 at 11:22 AM, wrote:

I never modify the stack size before. Can you give me a hint on how to adjust the size of stack in CCS?

I just found in the Build Options, in the Linker Tab, there is a setting for Stack Size. But how could I know the current stack size, so that I can use a larger setting?

Thank you

Hi there:
>
>I have difficulty to watch the value of a local varible using CCS. In the build option, I enable "Full Symbolic Debug". Disable all the opt options. Then I put a breakpoint at the place where I want the program to stop. However, when it stops, the local variables are not shown in the watch locals window. Even I add them in the watch window, it will tell me that my input is invalid and the identifier not found.
>
>I still can get the local variable value in the main function. This only happened when I try to debug inside some function I called during the main.
>
>I am wondering what i should do so that I can track the value of the local variables.
>
>Thank you for any suggestions
>
>Renaissance
>
>_____________________________________
>
> Start a New Thread

I'm using a linker command file to specify the memory sections in my
project. one of the lines I've got is:

-stack 0x3C00

which specifies how much space the stack should get allocated.

On my release code, I also tell the environment that I want it to generate a
map file so that I can see where all of the global symbols got located.
Looking in the map file I can find this section of output:

.stack 0 00028800 00003c00 UNINITIALIZED
00028800 00000008 rts6700.lib : boot.obj (.stack)

Which tells me that 0x3c00 was actually allocated, starting at address
0x28800. Also, something from the library gets put in the first 8 bytes of
the stack space. I don't know what it is, and am just assuming that it's a
necessary part of the platform code. Since it's only 8 bytes, I'm not overly
concerned about the space.

On Thu, Jun 18, 2009 at 11:22 AM, wrote:

> I never modify the stack size before. Can you give me a hint on how to
> adjust the size of stack in CCS?
>
> I just found in the Build Options, in the Linker Tab, there is a setting
> for Stack Size. But how could I know the current stack size, so that I can
> use a larger setting?
>
> Thank you
> Hi there:
> >
> >I have difficulty to watch the value of a local varible using CCS. In the
> build option, I enable "Full Symbolic Debug". Disable all the opt options.
> Then I put a breakpoint at the place where I want the program to stop.
> However, when it stops, the local variables are not shown in the watch
> locals window. Even I add them in the watch window, it will tell me that my
> input is invalid and the identifier not found.
> >
> >I still can get the local variable value in the main function. This only
> happened when I try to debug inside some function I called during the main.
> >
> >I am wondering what i should do so that I can track the value of the local
> variables.
> >
> >Thank you for any suggestions
> >
> >Renaissance
> >
> >_____________________________________
> >
> >
>
> Start a New Thread

Thank you Richard. I am sorry that the code is for special project in our
company and it is not allowed to be open. Also, it included more than 25
different files in total. I will try to figure out a way to duplicate the
issue in a non-industry-related method and then get back to you all.

Once again, thank you all for the help.

----- Original Message -----
From: "Richard Williams"
To: "Renaissance1975 - Gmail" ; "William C
Bonner"
Cc:
Sent: Thursday, June 18, 2009 2:27 PM
Subject: Re: [c6x] Re: CCS issues to watch local variables
> Renaissance,
>
> The problem may well be in the code.
>
> Past it into a post so we can look at it.
> Otherwise, we are just guessing.
>
> R. Williams
>
> ---------- Original Message -----------
> From: "Renaissance1975 - Gmail"
> To: "William C Bonner"
> Cc:
> Sent: Thu, 18 Jun 2009 13:33:48 -0700
> Subject: Re: [c6x] Re: CCS issues to watch local variables
>
>> Thank you so much for the suggestions.
>>
>> I think I can adjust the stack size. However, even though, during the
>> debug mode, I still could not get the local variables value in the
>> called function.
>>
>> I really have no other solutions....
>>
>> ----- Original Message -----
>> From: William C Bonner
>> To: r...@gmail.com
>> Cc: c...
>> Sent: Thursday, June 18, 2009 1:19 PM
>> Subject: Re: [c6x] Re: CCS issues to watch local variables
>>
>> I'm using a linker command file to specify the memory sections in my
>> project. one of the lines I've got is:
>>
>> -stack 0x3C00
>>
>> which specifies how much space the stack should get allocated.
>>
>> On my release code, I also tell the environment that I want it to
>> generate a map file so that I can see where all of the global symbols
>> got located. Looking in the map file I can find this section of output:
>>
>> .stack 0 00028800 00003c00 UNINITIALIZED
>> 00028800 00000008 rts6700.lib : boot.obj
>> (.stack)
>>
>> Which tells me that 0x3c00 was actually allocated, starting at
>> address 0x28800. Also, something from the library gets put in the
>> first 8 bytes of the stack space. I don't know what it is, and am
>> just assuming that it's a necessary part of the platform code. Since
>> it's only 8 bytes, I'm not overly concerned about the space.
>>
>> On Thu, Jun 18, 2009 at 11:22 AM, wrote:
>>
>> I never modify the stack size before. Can you give me a hint on
>> how to adjust the size of stack in CCS?
>>
>> I just found in the Build Options, in the Linker Tab, there is a
>> setting for Stack Size. But how could I know the current stack size,
>> so that I can use a larger setting?
>>
>> Thank you
>>
>> Hi there:
>> >
>> >I have difficulty to watch the value of a local varible using
>> CCS. In the build option, I enable "Full Symbolic Debug". Disable all
>> the opt options. Then I put a breakpoint at the place where I want the
>> program to stop. However, when it stops, the local variables are not
>> shown in the watch locals window. Even I add them in the watch window,
>> it will tell me that my input is invalid and the identifier not found.
>> > >I still can get the local variable value in the main
>> function. This only happened when I try to debug inside some function
>> I called during the main. > >I am wondering what i should do so
>> that I can track the value of the local variables. > >Thank you
>> for any suggestions > >Renaissance >
>>_____________________________________
>> >
>> >
> ------- End of Original Message -------
>

_____________________________________ Start a New Thread

Renaissance,

The problem may well be in the code.

Past it into a post so we can look at it.
Otherwise, we are just guessing.

R. Williams

---------- Original Message -----------
From: "Renaissance1975 - Gmail"
To: "William C Bonner"
Cc:
Sent: Thu, 18 Jun 2009 13:33:48 -0700
Subject: Re: [c6x] Re: CCS issues to watch local variables

> Thank you so much for the suggestions.
>
> I think I can adjust the stack size. However, even though, during the
> debug mode, I still could not get the local variables value in the
> called function.
>
> I really have no other solutions....
>
> ----- Original Message -----
> From: William C Bonner
> To: r...@gmail.com
> Cc: c...
> Sent: Thursday, June 18, 2009 1:19 PM
> Subject: Re: [c6x] Re: CCS issues to watch local variables
>
> I'm using a linker command file to specify the memory sections in my
> project. one of the lines I've got is:
>
> -stack 0x3C00
>
> which specifies how much space the stack should get allocated.
>
> On my release code, I also tell the environment that I want it to
> generate a map file so that I can see where all of the global symbols
> got located. Looking in the map file I can find this section of output:
>
> .stack 0 00028800 00003c00 UNINITIALIZED
> 00028800 00000008 rts6700.lib : boot.obj
> (.stack)
>
> Which tells me that 0x3c00 was actually allocated, starting at
> address 0x28800. Also, something from the library gets put in the
> first 8 bytes of the stack space. I don't know what it is, and am
> just assuming that it's a necessary part of the platform code. Since
> it's only 8 bytes, I'm not overly concerned about the space.
>
> On Thu, Jun 18, 2009 at 11:22 AM, wrote:
>
> I never modify the stack size before. Can you give me a hint on
> how to adjust the size of stack in CCS?
>
> I just found in the Build Options, in the Linker Tab, there is a
> setting for Stack Size. But how could I know the current stack size,
> so that I can use a larger setting?
>
> Thank you
>
> Hi there:
> >
> >I have difficulty to watch the value of a local varible using
> CCS. In the build option, I enable "Full Symbolic Debug". Disable all
> the opt options. Then I put a breakpoint at the place where I want the
> program to stop. However, when it stops, the local variables are not
> shown in the watch locals window. Even I add them in the watch window,
> it will tell me that my input is invalid and the identifier not found.
> > >I still can get the local variable value in the main
> function. This only happened when I try to debug inside some function
> I called during the main. > >I am wondering what i should do so
> that I can track the value of the local variables. > >Thank you
> for any suggestions > >Renaissance >
>_____________________________________
> >
> >
------- End of Original Message -------

_____________________________________ Start a New Thread

> I am sorry that the code is for special project in our
> company and it is not allowed to be open. Also, it included more than 25
> different files in total. I will try to figure out a way to duplicate the
> issue in a non-industry-related method and then get back to you all.

Renaissance,

There is no need to open the code to estimate amount of
the stack that is needed for an application. You only
need to recompile the whole project with the compiler
option "keep generated assembly files". Using these,
you may easily calculate the right amount of the stack.
Or, alternatively, the .map file would show the amount
of the stack, however it might be for an .obj in a
whole, not for each function in the .obj. Knowing it
its size for each function is important.

The bad thing about the stack is that it is allocated
dynamically, hence, over the life of your program, its
size may change. The good thing about the stack is that
each function allocates stack only once upon entry and
deallocates it (releases back to run time system) upon
return.

For example, consider a main() that call three functions
in sequence, and each of the functions is leaf - that is
does not call anything:

int main (void) // main alone takes X0 bytes on the stack
{
call fct1 (); // fct1 takes X1 bytes
call fct2 (); // fct1 takes X2 bytes
call fct3 (); // fct1 takes X3 bytes
}

In total, there will be MAX(X0,X1,X2,X3) bytes needed for the stack.

Now consider another situation, where main() calls ftc1(), then
fct1() calls fct2() and finally fct2 calls fct3():

main() { call fct1 (); }
fct1() { call fct2 (); }
fct2() { call fct3 (); }

The amount of the stack needed in this case is the sum of all 4 sizes,
X0+X1+X2+X3.

Even worse, let's assume that a function calls itself in a reccurrent
manner. Then the amount of the stack would increase by a multiple
of stack size allocated by the function. If the depth of the
reccurrence is, say 2000, then the stack is 2000*X.

Thus, when considering about amount of the stack needed for your
application, you must take into account any possible call tree
sequences. Actually, this is very much lile estimating an
asumptotic performance of an algorithm - see Aho, Hopecroft, Ullman.

Where to look at the generated assembly files. At the beginning of
each function in a file there is a header like that one below:

;******************************************************************************
;* FUNCTION NAME: copy_buffer *
;* *
;* Regs Modified : A0,A3,A4,A5,A6,A7,A8,A9,B4,B5,B6,B7,B8,B9,A16,A17, *
;* A18,A19,A20,A21,A22,A23,A24,A25,A26,A27,B16,B17, *
;* B18,B19,B20,B21,B22,B23,B24,B25,B26,B27 *
;* Regs Used : A0,A3,A4,A5,A6,A7,A8,A9,B3,B4,B5,B6,B7,B8,B9,A16,A17,*
;* A18,A19,A20,A21,A22,A23,A24,A25,A26,A27,B16,B17, *
;* B18,B19,B20,B21,B22,B23,B24,B25,B26,B27 *
;* Local Frame Size : 0 Args + 0 Auto + 0 Save = 0 byte *
;******************************************************************************

The "Local Frame Size" is the amount of the stack used by the function. Hey,
this one does not take anything from the stack! :)

Cheers,

Andrew
P.S.
The last but not least is to know the stack used by the RTS function
calls. Usually it is not a big issue, but again, the calls might
follow in the reccurrent manner.

_____________________________________ Start a New Thread

Ren..

A few comments interspersed , identified by RKW..

R. Williams
---------- Original Message -----------
From: a...@techemail.com
To: c...
Sent: Fri, 19 Jun 2009 06:32:00 -0400
Subject: [c6x] Re: CCS issues to watch local variables

> > I am sorry that the code is for special project in our
> > company and it is not allowed to be open. Also, it included more than 25
> > different files in total. I will try to figure out a way to duplicate the
> > issue in a non-industry-related method and then get back to you all.
>
> Renaissance,
>
> There is no need to open the code to estimate amount of
> the stack that is needed for an application. You only
> need to recompile the whole project with the compiler
> option "keep generated assembly files". Using these,
> you may easily calculate the right amount of the stack.
> Or, alternatively, the .map file would show the amount
> of the stack, however it might be for an .obj in a
> whole, not for each function in the .obj. Knowing it
> its size for each function is important.
>
> The bad thing about the stack is that it is allocated
> dynamically, hence, over the life of your program, its
> size may change. The good thing about the stack is that
> each function allocates stack only once upon entry and
> deallocates it (releases back to run time system) upon
> return.
> RKW: The stack is not allocated dynamically. Rather, its' "use" is dynamic
and the stack allocation is at link time.

> For example, consider a main() that call three functions
> in sequence, and each of the functions is leaf - that is
> does not call anything:
>
> int main (void) // main alone takes X0 bytes on the stack
> {
> call fct1 (); // fct1 takes X1 bytes
> call fct2 (); // fct1 takes X2 bytes
> call fct3 (); // fct1 takes X3 bytes
> }
>
> In total, there will be MAX(X0,X1,X2,X3) bytes needed for the stack.
> RKW: Actually the formula for stack usage in the above example would be
X0 + max(X1,X2,X3)


The best way to determine stack size/usage is to
1) fill the whole allocated stack area with a known value.
2) Run the program,
3) Stop the program at the point of interest,
4) examine the stack with the CCS.
------- End of Original Message -------

_____________________________________ Start a New Thread

On Fri, 19 Jun 2009, Renaissance1975 - Gmail wrote:

> pack_16b_8b_tightloop(
> short * restrict input_ptr,
> unsigned char * restrict output_ptr,
> int num_samples
> )

> ;******************************************************************************
> ;* FUNCTION NAME: pack_16b_8b_tightloop *
> ;* *
> ;* Regs Modified : A3,A4,A5,A6,B0,B4,B5,B6,B7,SP,B31 *
> ;* Regs Used : A3,A4,A5,A6,B0,B3,B4,B5,B6,B7,SP,B31 *
> ;* Local Frame Size : 0 Args + 32 Auto + 0 Save = 32 byte *
> ;******************************************************************************

Hmm... Can't see anything bad in this function. My cl6x (which is 6.1.9)
produces the same picture. Statics are stored in .far, locals in .stack,
and, yes, 32 byte - a space for 8 ints is allocated by ADDK .S2 -32,SP.

I currently run a project on a DM6446 using both cpus, the arm926 and c64+,
with local isrs, with interprocessor isrs, some code is optimized and has
no debug info, other code is being debugged, some vars are local, others
are global, some vars are just memory addresses for the interprocessor
communication, cache is off on the arm side and on on the c64+ side, and
I still can see any needed variable (if it is in the current scope, of course).
That's strange!

What can I suggest? It might be that the rest of your app has taken all the
available stack... If you have a spage meg (or more), do try to allocate it all
to the stack section (-stack_size=large_number). If this didn't work,
would you perhaps update your CCS installation. The current service pack
is somewhere like Rel. 11. Also, it might be that some erroneous memory
accesses due to an incorrect pointers might have overwritten part of
data/stack and that causes the problem for the debugger. Good luck!

Cheers,

Andrew

_____________________________________ Start a New Thread

On Fri, 19 Jun 2009, Richard Williams wrote:

> A few comments interspersed , identified by RKW..
>
>> For example, consider a main() that call three functions
>> in sequence, and each of the functions is leaf - that is
>> does not call anything:
>>
>> int main (void) // main alone takes X0 bytes on the stack
>> {
>> call fct1 (); // fct1 takes X1 bytes
>> call fct2 (); // fct1 takes X2 bytes
>> call fct3 (); // fct1 takes X3 bytes
>> }
>>
>> In total, there will be MAX(X0,X1,X2,X3) bytes needed for the stack.

> RKW: Actually the formula for stack usage in the above example would be
> X0 + max(X1,X2,X3)

Exactly so! That was just my fast fingers who were thinking! :)

Thanks,

Andrew

_____________________________________ Start a New Thread

On Fri, 19 Jun 2009, Richard Williams wrote:

> A few comments interspersed , identified by RKW..
>
> RKW: The stack is not allocated dynamically. Rather, its' "use" is dynamic
> and the stack allocation is at link time.

Hi Richard,

That was perhaps an imprecise terminology used by me. Thanks for clarification.
Still, it might be correct to say that the stack is reserved at the link time
and allocated dynamically, because the term "use" is also imprecise :)

Cheers,

Andrew

_____________________________________ Start a New Thread

Thanks a lot, Richard and Andrew.

Here is a part of the function I called, which has been generated into .asm file. In the function, I was trying to access the local variables, like i_3210, i_7654 and etc.
In fact, for this function, I can open the source code in C, which is shown in the following also. I could not find any information useful due to my insufficent background knowledge. I wish there is something which you guys find useful to help make a diagnosis.

Once again, thanks a lot.

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
#include

pack_16b_8b_tightloop(
short * restrict input_ptr,
unsigned char * restrict output_ptr,
int num_samples
)
{
int i;
static long long i_3210, i_7654;
static int i_32, i_10, i_76, i_54;
long long * restrict input_64_ptr;// *restrict input_64_ptr_q;
long long * restrict output_64_ptr;// *restrict output_64_ptr_q;
int out_i_7654, out_i_3210;

input_64_ptr = (long long * ) input_ptr;
output_64_ptr = (long long * ) output_ptr;

for (i =0; i < num_samples/8; i++)
{
// load the input data
i_3210 = *input_64_ptr++;
i_7654 = *input_64_ptr++;

// extract the data
i_32 = _hill(i_3210);
i_10 = _loll(i_3210);
i_76 = _hill(i_7654);
i_54 = _loll(i_7654);

// right shift (division)
i_32 = _shr2(i_32,0x7);
i_10 = _shr2(i_10,0x7);
i_76 = _shr2(i_76,0x7);
i_54 = _shr2(i_54,0x7);

// pack the signed 16-bit data to unsigned 8-bit data with saturation and truncation
out_i_3210 = _spacku4(i_32, i_10);
out_i_7654 = _spacku4(i_76, i_54);

// store the output
*output_64_ptr++ = _itoll(out_i_7654, out_i_3210);
}
}

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

;******************************************************************************
;* TMS320C6x C/C++ Codegen PC v6.0.8 *
;* Date/Time created: Thu Jun 18 20:10:36 2009 *
;******************************************************************************
.compiler_opts --c64p_l1d_workaroundault --endian=little --hll_source=on --mem_model:code=near --mem_model:data --silicon_versione00 --symdebug:dwarf

;******************************************************************************
;* GLOBAL FILE PARAMETERS *
;* *
;* Architecture : TMS320C64x+ *
;* Optimization : Disabled *
;* Optimizing for : Compile time, Ease of Development *
;* Based on options: no -o, no -ms *
;* Endian : Little *
;* Interrupt Thrshld : Disabled *
;* Data Access Model : Far *
;* Pipelining : Disabled *
;* Memory Aliases : Presume are aliases (pessimistic) *
;* Debug Info : DWARF Debug *
;* *
;******************************************************************************

.asg A15, FP
.asg B14, DP
.asg B15, SP
.global $bss
$C$DW$CU .dwtag DW_TAG_compile_unit
.dwattr $C$DW$CU, DW_AT_name("pack_16b_8b_tightloop.c")
.dwattr $C$DW$CU, DW_AT_producer("TMS320C6x C/C++ Codegen PC v6.0.8 Copyright (c) 1996-2006 Texas Instruments Incorporated")
.dwattr $C$DW$CU, DW_AT_TI_version(0x01)

$C$DW$1 .dwtag DW_TAG_subprogram, DW_AT_name("_hill")
.dwattr $C$DW$1, DW_AT_TI_symbol_name("__hill")
.dwattr $C$DW$1, DW_AT_type(*$C$DW$T$11)
.dwattr $C$DW$1, DW_AT_declaration
.dwattr $C$DW$1, DW_AT_external
$C$DW$2 .dwtag DW_TAG_formal_parameter, DW_AT_type(*$C$DW$T$14)
.dwendtag $C$DW$1
$C$DW$3 .dwtag DW_TAG_subprogram, DW_AT_name("_loll")
.dwattr $C$DW$3, DW_AT_TI_symbol_name("__loll")
.dwattr $C$DW$3, DW_AT_type(*$C$DW$T$11)
.dwattr $C$DW$3, DW_AT_declaration
.dwattr $C$DW$3, DW_AT_external
$C$DW$4 .dwtag DW_TAG_formal_parameter, DW_AT_type(*$C$DW$T$14)
.dwendtag $C$DW$3
$C$DW$5 .dwtag DW_TAG_subprogram, DW_AT_name("_itoll")
.dwattr $C$DW$5, DW_AT_TI_symbol_name("__itoll")
.dwattr $C$DW$5, DW_AT_type(*$C$DW$T$14)
.dwattr $C$DW$5, DW_AT_declaration
.dwattr $C$DW$5, DW_AT_external
$C$DW$6 .dwtag DW_TAG_formal_parameter, DW_AT_type(*$C$DW$T$11)
$C$DW$7 .dwtag DW_TAG_formal_parameter, DW_AT_type(*$C$DW$T$11)
.dwendtag $C$DW$5
$C$DW$8 .dwtag DW_TAG_subprogram, DW_AT_name("_shr2")
.dwattr $C$DW$8, DW_AT_TI_symbol_name("__shr2")
.dwattr $C$DW$8, DW_AT_type(*$C$DW$T$10)
.dwattr $C$DW$8, DW_AT_declaration
.dwattr $C$DW$8, DW_AT_external
$C$DW$9 .dwtag DW_TAG_formal_parameter, DW_AT_type(*$C$DW$T$10)
$C$DW$10 .dwtag DW_TAG_formal_parameter, DW_AT_type(*$C$DW$T$11)
.dwendtag $C$DW$8
$C$DW$11 .dwtag DW_TAG_subprogram, DW_AT_name("_spacku4")
.dwattr $C$DW$11, DW_AT_TI_symbol_name("__spacku4")
.dwattr $C$DW$11, DW_AT_type(*$C$DW$T$11)
.dwattr $C$DW$11, DW_AT_declaration
.dwattr $C$DW$11, DW_AT_external
$C$DW$12 .dwtag DW_TAG_formal_parameter, DW_AT_type(*$C$DW$T$10)
$C$DW$13 .dwtag DW_TAG_formal_parameter, DW_AT_type(*$C$DW$T$10)
.dwendtag $C$DW$11

_i_3210$1: .usect ".far",8,8
_i_7654$2: .usect ".far",8,8
_i_32$3: .usect ".far",4,4
_i_10$4: .usect ".far",4,4
_i_76$5: .usect ".far",4,4
_i_54$6: .usect ".far",4,4
; C:\CCStudio_v3.3\C6000\cgtools\bin\acp6x.exe -@C:\DOCUME~1\Renaissance\LOCALS~1\Temp\0446014
.sect ".text"
.global _pack_16b_8b_tightloop

$C$DW$14 .dwtag DW_TAG_subprogram, DW_AT_name("pack_16b_8b_tightloop")
.dwattr $C$DW$14, DW_AT_low_pc(_pack_16b_8b_tightloop)
.dwattr $C$DW$14, DW_AT_high_pc(0x00)
.dwattr $C$DW$14, DW_AT_TI_symbol_name("_pack_16b_8b_tightloop")
.dwattr $C$DW$14, DW_AT_external
.dwattr $C$DW$14, DW_AT_type(*$C$DW$T$10)
.dwattr $C$DW$14, DW_AT_TI_begin_file("pack_16b_8b_tightloop.c")
.dwattr $C$DW$14, DW_AT_TI_begin_line(0x19)
.dwattr $C$DW$14, DW_AT_TI_begin_column(0x01)
.dwpsn file "pack_16b_8b_tightloop.c",line 30,column 1,is_stmt,address _pack_16b_8b_tightloop

.dwfde $C$DW$CIE, _pack_16b_8b_tightloop
$C$DW$15 .dwtag DW_TAG_variable, DW_AT_name("i_3210")
.dwattr $C$DW$15, DW_AT_TI_symbol_name("_i_3210$1")
.dwattr $C$DW$15, DW_AT_type(*$C$DW$T$14)
.dwattr $C$DW$15, DW_AT_location[DW_OP_addr _i_3210$1]
$C$DW$16 .dwtag DW_TAG_variable, DW_AT_name("i_7654")
.dwattr $C$DW$16, DW_AT_TI_symbol_name("_i_7654$2")
.dwattr $C$DW$16, DW_AT_type(*$C$DW$T$14)
.dwattr $C$DW$16, DW_AT_location[DW_OP_addr _i_7654$2]
$C$DW$17 .dwtag DW_TAG_variable, DW_AT_name("i_32")
.dwattr $C$DW$17, DW_AT_TI_symbol_name("_i_32$3")
.dwattr $C$DW$17, DW_AT_type(*$C$DW$T$10)
.dwattr $C$DW$17, DW_AT_location[DW_OP_addr _i_32$3]
$C$DW$18 .dwtag DW_TAG_variable, DW_AT_name("i_10")
.dwattr $C$DW$18, DW_AT_TI_symbol_name("_i_10$4")
.dwattr $C$DW$18, DW_AT_type(*$C$DW$T$10)
.dwattr $C$DW$18, DW_AT_location[DW_OP_addr _i_10$4]
$C$DW$19 .dwtag DW_TAG_variable, DW_AT_name("i_76")
.dwattr $C$DW$19, DW_AT_TI_symbol_name("_i_76$5")
.dwattr $C$DW$19, DW_AT_type(*$C$DW$T$10)
.dwattr $C$DW$19, DW_AT_location[DW_OP_addr _i_76$5]
$C$DW$20 .dwtag DW_TAG_variable, DW_AT_name("i_54")
.dwattr $C$DW$20, DW_AT_TI_symbol_name("_i_54$6")
.dwattr $C$DW$20, DW_AT_type(*$C$DW$T$10)
.dwattr $C$DW$20, DW_AT_location[DW_OP_addr _i_54$6]

;******************************************************************************
;* FUNCTION NAME: pack_16b_8b_tightloop *
;* *
;* Regs Modified : A3,A4,A5,A6,B0,B4,B5,B6,B7,SP,B31 *
;* Regs Used : A3,A4,A5,A6,B0,B3,B4,B5,B6,B7,SP,B31 *
;* Local Frame Size : 0 Args + 32 Auto + 0 Save = 32 byte *
;******************************************************************************
_pack_16b_8b_tightloop:
.....

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
----- Original Message -----
From: Richard Williams
To: a...@techemail.com ; c...
Sent: Friday, June 19, 2009 5:32 AM
Subject: Re: [c6x] Re: CCS issues to watch local variables

Ren..

A few comments interspersed , identified by RKW..

R. Williams

---------- Original Message -----------
From: a...@techemail.com
To: c...
Sent: Fri, 19 Jun 2009 06:32:00 -0400
Subject: [c6x] Re: CCS issues to watch local variables

> > I am sorry that the code is for special project in our
> > company and it is not allowed to be open. Also, it included more than 25
> > different files in total. I will try to figure out a way to duplicate the
> > issue in a non-industry-related method and then get back to you all.
>
> Renaissance,
>
> There is no need to open the code to estimate amount of
> the stack that is needed for an application. You only
> need to recompile the whole project with the compiler
> option "keep generated assembly files". Using these,
> you may easily calculate the right amount of the stack.
> Or, alternatively, the .map file would show the amount
> of the stack, however it might be for an .obj in a
> whole, not for each function in the .obj. Knowing it
> its size for each function is important.
>
> The bad thing about the stack is that it is allocated
> dynamically, hence, over the life of your program, its
> size may change. The good thing about the stack is that
> each function allocates stack only once upon entry and
> deallocates it (releases back to run time system) upon
> return.
> RKW: The stack is not allocated dynamically. Rather, its' "use" is dynamic
and the stack allocation is at link time.

> For example, consider a main() that call three functions
> in sequence, and each of the functions is leaf - that is
> does not call anything:
>
> int main (void) // main alone takes X0 bytes on the stack
> {
> call fct1 (); // fct1 takes X1 bytes
> call fct2 (); // fct1 takes X2 bytes
> call fct3 (); // fct1 takes X3 bytes
> }
>
> In total, there will be MAX(X0,X1,X2,X3) bytes needed for the stack.
> RKW: Actually the formula for stack usage in the above example would be
X0 + max(X1,X2,X3)


The best way to determine stack size/usage is to
1) fill the whole allocated stack area with a known value.
2) Run the program,
3) Stop the program at the point of interest,
4) examine the stack with the CCS.
------- End of Original Message ------- Start a New Thread