DSPRelated.com
Forums
   Forums    More Forums    c6x  

Far Calls and Aggregate Data

Started by Brad Cadle ●June 24, 2003
I am using Code Composer 1.2 and have noticed the following. If I have a
line of code in a C file where I am placing a variable in an on chip memory
section and I compile a file with the compile options for far calls and
aggregate data, the linker does not tell me that there is a problem. In
this case I was trying to access a variable from a routine located in SDRAM
which means I need to access the variable as far data. The result is the
project builds but the routine access the wrong memory location. Here is
the pragma statement where I identify the placement of the variable,

"#pragma DATA_SECTION(g_mvTimeCntr,".onchipd");" Now, If I do the same with a function so I need far calls, the linker will
properly identify it as an error if a file does not have far calls enabled. 1) Does anyone know why the linker is not identifying the far data issue to
me?
2) Is this a problem in later releases of code composer?
3) Is there a work around that can be done which will force the linker or
compiler to identify the issue?
-------------
Brad Cadle
Senior Engineer DSP Technology
Bioscrypt Inc.
818-304-7162


Reply by ●June 25, 20032003-06-25
Brad Cadle wrote:

>I am using Code Composer 1.2 and have noticed the following. If I have a
>line of code in a C file where I am placing a variable in an on chip memory
>section and I compile a file with the compile options for far calls and
>aggregate data, the linker does not tell me that there is a problem. In
>this case I was trying to access a variable from a routine located in SDRAM
>which means I need to access the variable as far data. The result is the
>project builds but the routine access the wrong memory location. Here is
>the pragma statement where I identify the placement of the variable,
>
>"#pragma DATA_SECTION(g_mvTimeCntr,".onchipd");" >Now, If I do the same with a function so I need far calls, the linker will
>properly identify it as an error if a file does not have far calls enabled. >1) Does anyone know why the linker is not identifying the far data issue to
>me?
>2) Is this a problem in later releases of code composer?
>3) Is there a work around that can be done which will force the linker or
>compiler to identify the issue? >
I do not really understand but the #DATA_SECTION does not really have
anything to do with far.
Basiclly this is how things work:

There are 4 different memory models: ml0 to ml4 and they are (I might
mix them up so check the C manual)

-ml0 small memory model, nothing is far, max 32K .bss max 4M calls.
-ml1 far data ,max 4M calls.
-ml2 max 32K .bss, function calls can be to any part of the adderss range.
-ml3 .bss is not used , all global and static data in in .far section
and addressed with far fointers. Full address rang for calls.

-ml3 is ~10% larger footprint and ~10% more cylces than -ml0.

If you compile your code with -ml3 you should be able to place your
variable anywhere in the address space.

Another way would be to compile with -ml0 for best performance but
explicitly declare your varible with the "far" keyword:

far int g_mvTimeCntr;

If you access it from a different C file you should declare it:

extern far int g_mvTimeCntr;

If you do this you would not need the data section pragma but can just
place the .far section in external memory.

/Regards, P Ligander >
>
>-------------
>Brad Cadle
>Senior Engineer DSP Technology
>Bioscrypt Inc.
>818-304-7162 >_____________________________________
>Note: If you do a simple "reply" with your email client, only the author of
this message will receive your answer. You need to do a "reply all" if you want
your answer to be distributed to the entire group.
>
>_____________________________________
>About this discussion group:
>
>To Join: Send an email to
>
>To Post: Send an email to
>
>To Leave: Send an email to
>
>Archives: http://www.yahoogroups.com/group/c6x
>
>Other Groups: http://www.dsprelated.com >">http://docs.yahoo.com/info/terms/ >
>


Reply by jfbuggen ●June 26, 20032003-06-26
Hello,

I had noticed some time ago a strange behavior with CCS 2.1,
related to "far" definitions and #pragma DATA_SECTION.
Your problem could perhaps be related to this.
I didn't follow this topic very much later, so that I don't
know if this has been fixed in CCS 2.20.

If, in a .c file, you declare a variable :

#pragma DATA_SECTION(myVar, ".mySection");
unsigned long myVar;

The presence of the pragma means that you want to
put the variable in a specific section. Since this is
not the .bss (32K max) section, the compiler has to use
a "far" addressing to access the variable.
Thus, the presence of the pargma tells to the compiler
that it has to use "far" addressing, even if you didn't
use the keyword "far" when declaring the variable.

If you have declared the same variable in a header file :

extern unsigned long myVar;

...and you include this header file in another .c file,
when compiling this second .c file, the compiler is not
aware of the fact that myVar is not in .bss (since there
is no "far" keyword, and the pragma DATA_SECTION may not
be put in the header file).
As a result, the compiler performs "near" addressing to
access the myVar. This is of course an error.

The workaround I used is to use explicitely the keyword
"far" for every variable placed in a specific section.
Thus, everytime you use the #pragma DATA_SECTION, you should
add the "far" keyword in the variable declaration :

C file :
#pragma DATA_SECTION(myVar, ".mySection");
far unsigned long myVar;

H file :
extern far unsigned long myVar;

Regards,

J-F


Reply by Brad Cadle ●June 26, 20032003-06-26
This sounds exactly like my problem.

I have a header file with variable declared as extern, so it is likely as
you described. Presumably when I forced the compiler to use far calls for
the file accessing the variable this clears the problem. I will try to use
the far keyword and see if this will notify me of the problem if I choose
near calls.

Thanks,
Brad

-----Original Message-----
From: jfbuggen [mailto:]
Sent: Thursday, June 26, 2003 1:09 AM
To:
Subject: [c6x] Re: Far Calls and Aggregate Data Hello,

I had noticed some time ago a strange behavior with CCS 2.1, related to
"far" definitions and #pragma DATA_SECTION. Your problem could perhaps be
related to this. I didn't follow this topic very much later, so that I don't
know if this has been fixed in CCS 2.20.

If, in a .c file, you declare a variable :

#pragma DATA_SECTION(myVar, ".mySection");
unsigned long myVar;

The presence of the pragma means that you want to
put the variable in a specific section. Since this is
not the .bss (32K max) section, the compiler has to use
a "far" addressing to access the variable.
Thus, the presence of the pargma tells to the compiler
that it has to use "far" addressing, even if you didn't
use the keyword "far" when declaring the variable.

If you have declared the same variable in a header file :

extern unsigned long myVar;

...and you include this header file in another .c file,
when compiling this second .c file, the compiler is not
aware of the fact that myVar is not in .bss (since there
is no "far" keyword, and the pragma DATA_SECTION may not
be put in the header file).
As a result, the compiler performs "near" addressing to
access the myVar. This is of course an error.

The workaround I used is to use explicitely the keyword
"far" for every variable placed in a specific section.
Thus, everytime you use the #pragma DATA_SECTION, you should add the "far"
keyword in the variable declaration :

C file :
#pragma DATA_SECTION(myVar, ".mySection");
far unsigned long myVar;

H file :
extern far unsigned long myVar;

Regards,

J-F
_____________________________________
Note: If you do a simple "reply" with your email client, only the author of
this message will receive your answer. You need to do a "reply all" if you
want your answer to be distributed to the entire group.

_____________________________________
About this discussion group:

To Join: Send an email to

To Post: Send an email to

To Leave: Send an email to

Archives: http://www.yahoogroups.com/group/c6x

Other Groups: http://www.dsprelated.com ">http://docs.yahoo.com/info/terms/



Reply by Jeff Brower ●June 26, 20032003-06-26
JF-

Thanks, great explanation. That might explain something else I saw on a project
a
while ago.

-Jeff

jfbuggen wrote:
>
> Hello,
>
> I had noticed some time ago a strange behavior with CCS 2.1,
> related to "far" definitions and #pragma DATA_SECTION.
> Your problem could perhaps be related to this.
> I didn't follow this topic very much later, so that I don't
> know if this has been fixed in CCS 2.20.
>
> If, in a .c file, you declare a variable :
>
> #pragma DATA_SECTION(myVar, ".mySection");
> unsigned long myVar;
>
> The presence of the pragma means that you want to
> put the variable in a specific section. Since this is
> not the .bss (32K max) section, the compiler has to use
> a "far" addressing to access the variable.
> Thus, the presence of the pargma tells to the compiler
> that it has to use "far" addressing, even if you didn't
> use the keyword "far" when declaring the variable.
>
> If you have declared the same variable in a header file :
>
> extern unsigned long myVar;
>
> ...and you include this header file in another .c file,
> when compiling this second .c file, the compiler is not
> aware of the fact that myVar is not in .bss (since there
> is no "far" keyword, and the pragma DATA_SECTION may not
> be put in the header file).
> As a result, the compiler performs "near" addressing to
> access the myVar. This is of course an error.
>
> The workaround I used is to use explicitely the keyword
> "far" for every variable placed in a specific section.
> Thus, everytime you use the #pragma DATA_SECTION, you should
> add the "far" keyword in the variable declaration :
>
> C file :
> #pragma DATA_SECTION(myVar, ".mySection");
> far unsigned long myVar;
>
> H file :
> extern far unsigned long myVar;
>
> Regards,
>
> J-F
Reply by ●June 26, 20032003-06-26
Jeff Brower wrote:

>JF-
>
>Thanks, great explanation. That might explain something else I saw on a
project a
>while ago. That was sort of the situation. However Ther was no software that came
with the XDS560. It was all updates from TIs website.
It was all extremely smoth out of the box.

/Regards, P Ligander >-Jeff
>
>jfbuggen wrote: >>Hello,
>>
>>I had noticed some time ago a strange behavior with CCS 2.1,
>>related to "far" definitions and #pragma DATA_SECTION.
>>Your problem could perhaps be related to this.
>>I didn't follow this topic very much later, so that I don't
>>know if this has been fixed in CCS 2.20.
>>
>>If, in a .c file, you declare a variable :
>>
>>#pragma DATA_SECTION(myVar, ".mySection");
>>unsigned long myVar;
>>
>>The presence of the pragma means that you want to
>>put the variable in a specific section. Since this is
>>not the .bss (32K max) section, the compiler has to use
>>a "far" addressing to access the variable.
>>Thus, the presence of the pargma tells to the compiler
>>that it has to use "far" addressing, even if you didn't
>>use the keyword "far" when declaring the variable.
>>
>>If you have declared the same variable in a header file :
>>
>>extern unsigned long myVar;
>>
>>...and you include this header file in another .c file,
>>when compiling this second .c file, the compiler is not
>>aware of the fact that myVar is not in .bss (since there
>>is no "far" keyword, and the pragma DATA_SECTION may not
>>be put in the header file).
>>As a result, the compiler performs "near" addressing to
>>access the myVar. This is of course an error.
>>
>>The workaround I used is to use explicitely the keyword
>>"far" for every variable placed in a specific section.
>>Thus, everytime you use the #pragma DATA_SECTION, you should
>>add the "far" keyword in the variable declaration :
>>
>>C file :
>>#pragma DATA_SECTION(myVar, ".mySection");
>>far unsigned long myVar;
>>
>>H file :
>>extern far unsigned long myVar;
>>
>>Regards,
>>
>>J-F
>>
>>
>
>_____________________________________
>Note: If you do a simple "reply" with your email client, only the author of
this message will receive your answer. You need to do a "reply all" if you want
your answer to be distributed to the entire group.
>
>_____________________________________
>About this discussion group:
>
>To Join: Send an email to
>
>To Post: Send an email to
>
>To Leave: Send an email to
>
>Archives: http://www.yahoogroups.com/group/c6x
>
>Other Groups: http://www.dsprelated.com >">http://docs.yahoo.com/info/terms/ >
>