TMS320F280040-Q1: How to process a data larger than 32-bit in TMS320F28004x?

Let me check with compiler team and get back to you by Tuesday.

Thanks a lot Santosh!

Change to using a 64-bit wide floating point type.  If you build with the older COFF ABI, then change from the type double to long double, and call sqrtl instead of sqrt.  If you build with the newer EABI (by using the build option --abi=eabi), then the type double is 64-bits wide, and the default sqrt function is also 64-bits wide.

Thanks and regards,

-George

Thank George for your reply. I chose the output format as EABI. Where to set the build option --abi=eabi? I didn't find it at C2000 compiler -> Processor options.

I found that in ./device/driverlib/ccs/driverlib.projectspec, there is --abi=coffabi.

In the makefile and makefiles in subfolders, there is --abi=eabi.

The actual result is that the double type overflows for data larger than 32-bit.

Crane Shao said:

Where to set the build option --abi=eabi?

This appears at a higher level of the project configuration.  In CCS, right-click on the project name and go to Properties, then click on General in the left pane.  Use the drop-down box titled Output format.  A screen shot is below.

Thanks and regards,

-George

It is already set as this. But it still look double as 32-bit. I wondering why in this file ./device/driverlib/ccs/driverlib.projectspec, there is still --abi=coffabi.

And I tried long double and it works. 

Ok got it. Yes it is based on a C200Ware example. Is there any way to change the setting in driverlib.projectspec?

Crane Shao said:

Is there any way to change the setting in driverlib.projectspec?

That is not needed.  To understand why, please see the article ProjectSpecs in CCS.  It is better to change the project settings after you have imported the .projectspec.

In your specific case, changing to EABI will probably cause the project to not build, because it links against other libraries from C2000Ware which are built for the older COFF ABI.  If that is the case, then the best solution for your problem is to use type long double and call sqrtl.

Thanks and regards,

-George

Ok. So it won't affect the output file being in ELF format as the output format is already changed in the property - general, right?

I presume the "it" in this sentence ...

Crane Shao said:

So it won't affect the output file being in ELF format

... refers to the setting --abi=coffabi in the .projectspec file.  If so, you are correct.

Thanks and regards,

-George

Ok. One more question, it seems right now the program is compiled part as COFFABI and part as EABI, might this cause anything unexpected?

Crane Shao said:

it seems right now the program is compiled part as COFFABI and part as EABI

That's not possible. When it is attempted, the linker detects it and issues an error.

Thanks and regards,

-George

I think it's compiled as EABI because I observe three things:

1. this advice as in below screenshot

2. it doesn't recognize the symbols with a leading underscore in linker file. So I have to change these symbols:

/* LOAD_START(_RamfuncsLoadStart),
LOAD_SIZE(_RamfuncsLoadSize),
LOAD_END(_RamfuncsLoadEnd),
RUN_START(_RamfuncsRunStart),
RUN_SIZE(_RamfuncsRunSize),
RUN_END(_RamfuncsRunEnd),*/

LOAD_START(RamfuncsLoadStart),
LOAD_SIZE(RamfuncsLoadSize),
LOAD_END(RamfuncsLoadEnd),
RUN_START(RamfuncsRunStart),
RUN_SIZE(RamfuncsRunSize),
RUN_END(RamfuncsRunEnd),

3. the output file is most likely ELF format.

But at the same time, it still look double type as 32-bit.

For the source file with the problem sqrt computations, please follow the directions in the article How to Submit a Compiler Test Case.

Thanks and regards,

-George

Ok. Right now sqrt computation issue is clear. I need to use long double to do the calculation and it works that way.

The issue right now is that I observe that the compiler is compiling in both COFFABI and EABI. I think I need to send the whole project with necessary source files to you. What do you think?

Crane Shao said:

I think I need to send the whole project with necessary source files to you.

Instead, show how the project is built. Please rebuild the entire project.  One way to do that is to right-click on the name of the project and select Rebuild Project.  Then save the contents of the Console (not Problems) view to a text file.  Use the icon named Copy Build Log.  When you name the log file, be sure to use the file extension .txt.  Please attach that text file to your next post.

Thanks and regards,

-George

Here is the build log when rebuilding the project. Thanks!

 6747.build_log.txt

Crane Shao said:

I observe that the compiler is compiling in both COFFABI and EABI

After inspecting the build log, I can confirm this is incorrect.  The entire build uses --abi=eabi.  

Crane Shao said:

Right now sqrt computation issue is clear. I need to use long double to do the calculation and it works that way.

I cannot explain that.  When you build with --abi=eabi, long double and double are the same.  So are sqrt and sqrtl.  Therefore, changing from double to long double should make no difference.

Thanks and regards,

-George

Crane Shao said:

I am trying to get a square root of -15 and -2330. Here is the result I am getting right now: -10363.

For the following statement:

temp = (real_data * real_data) + (imag_data * imag_data);

the debugger output shows:

• real_data and imag_data are of type int
• temp is of type double

In a C2000 CPU int is 16-bits. The expression (real_data * real_data) + (imag_data * imag_data) is calculated using 16-bits. With real_data=-15 and imag_data=-2330 this calculation as 16-bits overflows and results in the value of -10363.

Therefore, the calculation needs casts, to cause the calculation to use more than 16-bits.

Either using 32-bit integers:

temp = ((int32_t) real_data * (int32_t) real_data) + ((int32_t) imag_data * (int32_t) imag_data);

Where int32_t is defined in <stdint.h>

Or using doubles:

temp = ((double) real_data * (double) real_data) + ((double) imag_data * (double) imag_data);

That's why it is so weird. I used double before and it didn't work. That's why I asked the first question in this thread. And after I changed the type to long double, the issue was addressed. Then we did find that there is the setting --abi=coffabi in the .projectspec file.

Anyway, the initial issues is already addressed. Right now, I am just wondering if there will be any unexpected result due to this weird behavior.

Thanks Chester for your reply. 

The post from Chester is correct.  The important clue is the screen shot in the first post.  The variables real_data and imag_data are int.  I somehow thought they were float or double.  I apologize for overlooking that.

Thanks and regards,

-George

Ok got it. I tried and yes. Great!

Then the last question is, for the setting --abi=coffabi in the .projectspec file can just be ignored, right?

Crane Shao said:

the setting --abi=coffabi in the .projectspec file can just be ignored

Correct.  -George