Readme for C2000 Code Generation Tools v20.2.7.LTS (2024)

Table of Contents

The C2000 CGT v20.2.0.LTS release is a long term support (LTS) release. This release will be supported for roughly 2 years with periodic bug fix updates.

Documentation for the “TI C2000 Optimizing Compiler User’s Guide” and the “TI C2000 Assembly Language User’s Guide” is available online at:

https://www.ti.com/tool/C2000-CGT

Questions concerning TI Code Generation Tools can be posted to the TI E2E Community forums. The “Development Tools” forum can be found at:

http://e2e.ti.com/support/tools

Compiler defect reports can be tracked at the Development Tools bug database at:

https://sir.ext.ti.com/

Integer Division Unit (HWINTDIV) updates

The Integer Division Unit feature support has below updates. Feature enabled with --idiv_support=idiv0 and requires --abi=eabi and --float_support=fpu32/fpu64.

• Improved performance for several HWINTDIV routines: In 18.12.0.LTS release, the initial HWINTDIV implementation had inefficiencies with directly loading from memory to fpu registers affecting almost all HWINTDIV sequences. The fpu register loads were being inefficiently loaded initially to non-fpu registers before final load to fpu registers resulting in unecessary register-to-register moves along with additional NOPs.

  This was fixed in 19.6.0.STS

• Improved performance for several HWINTDIV routines: The original HWINTDIV implementation in 18.12.0.LTS did not implement the most optimal sequences for i64/i32, i64/u32, and u64/u32 which instead leveraged slower 64/64 sequences.

  See Also

  Readme for C2000 Code Generation Tools v22.6.1.LTSReadme for C2000 Code Generation Tools v21.6.0.LTSC2000 C/C++ Code Generation Tools v20.2.1.LTS Release Notes

  Implemented the optimial HWINTDIV sequences for:

   i64/i32 traditional, euclidean, and modulo
   i64/u32 traditional, euclidean, and modulo
   u64/u32 traditional 

  The original implementation had all intrinsics returning either ldiv_t, or lldiv_t (and unsigned equivalents). However, below intrinsics:

   i64/i32 traditional, euclidean, and modulo
   i64/u32 euclidean, and modulo (not traditional)
   u64/u32 traditional 

  return llong quotient with long remainder which required updates to stdlib.h to include below new return types:

   typedef struct { long long quot; long rem; } __llldiv_t;
   typedef struct { unsigned long long quot; unsigned long rem; } __ullldiv_t; 

• Assembler pipeline detection check HWINTDIV instructions cannot be placed in the delay slots for any FPU multicycle instructions. Assembler pipeline checks have been added to error if this is detected.

• Build attributes Below HWINTDIV build attributes were added. View build attribute settings using the object file dump tool: ofd2000
  

   Tag_IDIV 1 (IDIV 0) 

• Predefined macros for assembler/linker Below HWINTDIV predefined macros were added for use in assembling/linking:

   assembler: .TMS320C2800_IDIV set to 1 if --idiv_support=idiv0
   linker: __TMS320C28XX_IDIV__ set to 1 if --idiv_support=idiv0 

Support inline memcpy operations larger than 255 words

Inlining of memcpy for operations less than or equal 255 words is already supported with use of the instruction: RPT #imm

Support has been added for inlining memcpy of operations larger than 255 words by using the RPT instruction with register operand.

Both memcpy inlining uses of RPT can be disabled with --rpt_threshold

FPU64 Run Time Support (RTS) library routine updates

• Trig float routines: Below RTS library routines had implementations that included increased 32-bit precision if --float_support=fpu64 was available, however, these routines have been updated to use the same implementation for both fpu32 or fpu64 modes:

   sinf(float) cosf(float) tanf(float) cbrtf(float) 

  For improved floating point precision with fpu64 mode, use the double routines.

• sqrt(double): The RTS math library sqrtf(float) routine included use of the EISQRTF32 instruction if --float_support=fpu32 was enabled.
  Added similar support for sqrt(double) to use the EISQRTF64 instruction if --float_support=fpu64 is enabled.

New diagnostic checks

• Linker/assembler diagnostic for blocked vs non-blocked data access: New linker/assembler diagnostic checks were added to detect when data accesses that assume data is blocked are made to non-blocked definitions. This was for Jira feature ticket CODEGEN-1407.

  For more background on data blocking see:
  https://e2e.ti.com/blogs_/archives/b/toolsinsider/archive/2016/11/17/data-blocking-in-the-c2000-mcu-compiler-explained?keyMatch=data%20blocking&tisearch=Search-EN-Everything

  The common case for this is a global CLA definition that is used in C28 code. However, the diagnostic is not limited to CLA definitions and instead more generically checks for blocked accesses with non-blocked definitions.

  COFF and EABI use different implementations. See spru514 Compiler User guide for details on COFF vs EABI data page optimizations and data blocking.

  COFF:
  The COFF implementation is based on leveraging an unused symbol type.

  EABI:
  The EABI implementation added a new relocation to indicate a blocked access relocation. The relocation is exactly the same but with suffix _BLKD

  Both COFF/EABI implementations use a new $BLOCKED() built-in function in assembly for the compiler to mark accesses as blocked during code generation.

  Example assembler warning:

   “test_blocked.asm”, WARNING! at line 59: [W0000] Definition for
   symbol _sym_block is
   non-blocked while
   references indicate
   blocked access with
   $BLOCKED()
   operator.
   MOV @$BLOCKED(_sym_block)+2,#0
  

  Example linker warning:
  

   warning: Symbol, “sym_blocked”, referenced in “test.obj”, assumes that data 
   is blocked but is accessing non-blocked data in “test2.obj”. Runtime
   failures may result. 

• Linker diagnostic for function calls between CLA and C28 code A new linker diagnostic check was added to detect when C28 or CLA code branches to code instead compiled for the CLA or C28.

  COFF and EABI use different implementations.

  COFF:
  The COFF implementation is based on leveraging an unused symbol type.

  EABI:
  The EABI implementation added a new relocation to indicate both direct and indirect function calls. The relocation is exactly the same but with suffix _BR

  The more common case to detect is for direct function calls. eg:

   LCR #func 

  For indirect function calls, both COFF/EABI implementations use a new CALL() built-in function in assembly for the compiler to mark address loads that are used in subsequent indirect-function calls. eg:
  

   MOVL XAR7, #CALL(func)
   LCR *XAR7 

  Example linker warning:
  

   warning: Invalid to call C28 function “_foo_c28" defined in “test.o” from CLA file “test_cla.o”
   warning: Invalid to call CLA function “_foo_cla" defined in “test_cla.o” from C28 file “test.o” 

• Additional Assembler diagnostics added for FPU64: The existing assembler diagnostics for detecting FPU64 instructions/operands not supported in FPU32 mode (–float_support=fpu32) have been updated to emit errors for below cases:

   Use of RaL operand with below in fpu32 mode:
   MOVDD32, MOVXI and MOV32
   Use of Ra operand with below in fpu32 mode:
   MOVI32 and MOVF32
   Use of below instructions in fpu32 mode:
   F32DTOF64 and MOVIZF64 

  NOTE: SWAPF, ZERO and MOVIZ use the same opcode for both fpu32 and fpu64 and both operands are accepted in either mode.
  On fpu32-only hardware, the instructions only operate on 32-bits. On fpu64 hardware, the instructions only operate on 64-bits.

• Additional advice with --advice:performance for EABI with fpu32 mode: With recent release of EABI support, floating point doubles have changed from being 32-bits in COFF ABI, to 64-bits for EABI.
  As a migration aid, --advice:performance=all will now additionally emit below advice if double floating point operations are detected when compiling for EABI with --float_support=fpu32:
  

   (Performance) EABI double precision is 64-bits as opposed to 32-bits for COFF. 
   Consider changing doubles to floats for improved performance in FPU32-mode. 

  Above advice can be disabled with either of below options:

   --advice:performance=none or --float_operations_allowed=all 

Hex utility --cmac option, supported added for --boot tables

The hex conversion utility’s Cipher-based Message Authentication Protocol (CMAC) feature now supports boot tables with CMAC tags.

To enable, use --cmac=key_file with --boot along with other required boot table options. The CMAC algorithm assumes a fill value of 1’s for gaps between boot table regions which requires setting --fill.

Hex utility --cmac option (cipher-based message authentication protocol)

The hex conversion utility supports the secure flash boot capability provided by TMS320F2838x devices, which have both C28 and ARM cores. The secure flash boot applies the Cipher-based Message Authentication Protocol (CMAC) algorithm to verify CMAC tags for regions of allocated memory.

In order to apply the CMAC algorithm to the appropriate regions in allocated memory, use the hex conversion utility as follows: --cmac=file where file contains a 128-bit hex CMAC key

NOTE: above additionally requires --image or --load_image options.

CMAC tag locations need to be defined in the user’s C code using below symbols along with LOCATION and RETAIN pragmas: secure boot regions: cmac_sb_1 cmac_sb_2 cmac_sb_3 or cmac_sb_4 user-specified region: cmac_all

The hex utility will then apply the CMAC algorithm to all the CMAC tags defined in the user’s C code.

See TMS320C28x Assembly Language Tools User Guide for details.

VCU register save/restore support for interrupt service routines

In prior releases, interrupt service routines (ISR) did not save/restore VCU registers.

Below new option generates VCU register save/restore to stack for ISR’s so vcu code can be re-entrant. If an ISR interrupts a VCU computation then it will not impact results.

 --isr_save_vcu_regs=on,off 

NOTE: VCU save/restore are only emitted for ISR’s that call other functions since leaf ISR routines will not have any VCU register usage as there is no current VCU code generation aside from below save/restore.

For --vcu_support=vcu0/vcu2, below are added to ISR’s:

 VMOV32 SP++,VCRC 
 VMOV32 SP++,VSTATUS
 …
 VMOV32 VSTATUS,–SP 
 VMOV32 VCRC,–SP 
 

For --vcu_support=vcrc, below are added to ISR’s:

 VMOV32 SP++,VCRC 
 VMOV32 SP++,VSTATUS
 VMOV32 SP++,VCRCPOLY 
 VMOV32 SP++,VCRCSIZE 
 …
 VMOV32 VCRCSIZE,–SP 
 VMOV32 VCRCPOLY,–SP 
 VMOV32 VSTATUS,–SP 
 VMOV32 VCRC,–SP 
 

Default file extension for compiler generated object files

The default file extensions for object files created by the compiler have changed in order to prevent conflicts when C and C++ files have the same names. Object files generated from C source files have the .c.obj extension. Object files generated from C++ source files have the .cpp.obj extension.

Starting with C2000 CGT v20.2.5.LTS, MISRA-C 2004 checking support has been deprecated. The existing MISRA checking functionality will remain in further patch versions of this compiler stream as is, but no further issues will be addressed.

Resolved defects in v20.2.7.LTS:

The following link will lead to an updated list of known defects in this release:

Known defects – dynamic