In this TI Wiki
http://processors.wiki.ti.com/index.php/C2000_CLA_C_Compiler
It says
Local variables and compiler temps are placed into a scratchpad memory area. On older CGT (before 6.4.0) these variables were accessed directly using the symbols '__cla_scratchpad_start' and '__cla_scratchpad_end' and it was expected that the user would manage this area and define these symbols using a linker command file. In CGT 6.4.0 (and above) these variables are placed in a ".scratchpad" memory section, which the compiler will then partition into local frames, one for the all eight tasks, and one for each leaf function. These local frames will have unique symbols that the compiler will use to access variables.
...
The old convention for CLAScratch will still be supported by the new compiler, albeit, inefficiently from a memory allocation standpoint. The new compiler creates a common local frame for the 8 tasks, i.e. each task's local frame is overlayed on top of each other - they use the same memory locations; this is possible since there is no nesting of tasks, so one task cannot corrupt the scratch area of another. By having the CLAScratch memory section, the compiler cannot take advantage of the overlaying strategy and is, instead, forced to allocate each task's locals in separate locations within the scratchpad.
So your .cmd file either looks like this (6.2.x and older)
// Define a size for the CLA scratchpad area that will be used
// by the CLA compiler for local symbols and temps
// Also force references to the special symbols that mark the
// scratchpad area.
CLA_SCRATCHPAD_SIZE = 0x100; // If using --define CLA_SCRATCHPAD_SIZE=0x100, remove this line
--undef_sym=__cla_scratchpad_end
--undef_sym=__cla_scratchpad_start
.....
MEMORY
{
.....
}
SECTIONS
{
//
// Must be allocated to memory the CLA has write access to
//
CLAscratch :
{ *.obj(CLAscratch)
. += CLA_SCRATCHPAD_SIZE;
*.obj(CLAscratch_end) } > CLARAM1, PAGE = 1
}
or like this (6.4.x and newer)
.....
MEMORY
{
.....
}
SECTIONS
{
//
// Must be allocated to memory the CLA has write access to
//
.scratchpad : > CLARAM1, PAGE = 1
}
One thing to note is that the CLA math library still uses the "CLAscratch" section. So even with 6.4.x compiler, if you are using CLA math library, you'd need to do the .cmd file as if you had 6.2.x or older.
I have tried to modify the CLA math library source and replace every .usect "CLAscratch" with .usect ".scratchpad" ?? Then recompile the library and use that one instead (with 6.4.x or newer). Then you would need to only specify .scratchpad in your .cmd file, even if you are using the CLA math library.
Should I have any concern about the CLA math library functions having the same frame as the overlayed task frames? Or are they considered leaf functions that have their own frames?
From what I see, it looks like they are all using the same frame:
This is how it was before with the old convention:
