Compiler/TDA4VMXEVM: [C71]How to insert “NOP" in the C code of C71 DSP？

Compile Error:

"[E0300] NOP is a reseved identifier"

Hi Todd,

Here's the situation.

We found that if we use statements like vec.even or vec.odd in our code, the generated assembly instructions will have timing errors after the compiler optimizing. Now we use the __select instruction instead of even and odd, and the assembly instructions are optimized to execute the correctly.
I'm guessing that maybe the opencl style code is not well supported by the compiler?

Regards，

Lance

Lance,

Can you please attach a reproducible testcase, as any type of error such as you describe is unexpected. Please also point out if you are able in the assembly code what you believe to be incorrect. The -ppo compiler option can help you produce a single-file .pp file that you can attach.

Thanks,

-Todd

Todd，

Here is the assembly code with origin C code:

The assembly code of C code line 243, should process before line 245.

But You can see that there is a timing error.

Lance

Lance,

Is this assembly code in PROTected or UNPROTtected mode? To me, it looks like PROT mode. Therefore, the CPU will stall before the VSPTRUNC for the appropriate number of cycles until VBL0 from the VADDSP is ready. The compiler only uses UNPROT mode for software pipelined loops.

Second, the VADDSP looks wrong (unless the compiler knows even and odd vectors are the same values). There needs to be processing to get the even and odd portions of val_fp. Which version of the compiler are you using, and what compiler options? Also, an entire C file that demonstrates the problem may be required for us to reproduce any issue.

-Todd

Hi Todd,

Could you please tell me how to set Portected or Unprotected Mode and what are the differences?

I use concerto to compile our codes and add --c_src_interlist option in makerules/concerto/compilers/cgt7x.mak to save asm.

The sdk version we use is j7_06_02_00_21.

It's strange that we put these lines of code into CCS and compiled them using -O3 and they came out right.

We're sorry we can't give you the entire C file for reasons of commercial confidentiality, but we can't reproduce the problem when we compile these lines of code separately.

I'm guessing maybe it's related to other compiler configurations in concerto?

Lance

Lance,

In protected mode, the CPU will stall if a value isn't ready before it is used. In unprotected mode, it doesn't. Unprotected mode is useful for when the compiler needs to perform software pipelining, where multiple writes to the same register are in flight at once.

The PROT, PROTCLR, and UNPROT instructions are used by the compiler to switch modes. They are not to be used by the user.

If you can reproduce the problem with a non-proprietary example, we can proceed on looking into any issue.

I think that version of the SDK uses the 1.2.0.STS version of the C7000 compiler. There have been many defects fixed since then. Can you update to a newer version of the SDK and/or compiler? Use cl7x -version to see the compiler version.

https://www.ti.com/tool/download/C7000-CGT-1

-Todd

Todd,

I updated my CGT to 1.3.0 and tried then.

But those statements are still compiled wrongly.

We'll still use the workaround method for now, and will check back to verify this later when we have some free time. We're sorry that we can't provide you with code that reproduces the problem, because we have no problem compiling these statements separately! 

Thanks a lot!

Lance