NOTICE: The Processors Wiki will End-of-Life on January 15, 2021. It is recommended to download any files or other content you may need that are hosted on processors.wiki.ti.com. The site is now set to read only.

C6000 Optimizing C/C++ Compiler Errata

From Texas Instruments Wiki
Jump to: navigation, search

Options Errata[edit]

--ppm
The Compiler User's Guide is missing information on the -ppm switch, used to generate a list of predefined and user defined macros. The details are:
-ppm[=filename]
Generate a list of predefined and user defined macros for the source file into the file <filename>.pp and then exit. Optionally, name the output file. The output will include only those files directly included by the source file. Also see the -ppa option to continue compilation after generating the macro list (similar to gcc).
This option became available starting with version 6.1.0.
--no_const_clink
The Compiler User's Guide is missing information about the --no_const_clink switch. This switch prevents the compiler from generating .clink directives (conditional linking) for const global arrays. By default, these arrays are placed in a .const subsection and conditionally linked.

Section 6.1 wchar_t Description[edit]

The User's Guide includes this incorrect statement:

"The run-time library has minimal support for wide and multi-byte characters. The type wchar_t is implemented as int."

This should read as:

"The run-time library has minimal support for wide and multi-byte characters. The type wchar_t is implemented as unsigned short."

Section 6.2 Characterics of TMS320C6000 C++[edit]

The exceptions to the standard list includes these bullets that are incorrect and not applicable to the current compiler toolset:

  • Two-phase name binding in templates, as described in [tesp.res] and [temp.dep] of the standard, is not implemented.
  • Template parameters are not implemented.
  • The export keyword for templates is not implemented.
  • A typedef of a function type cannot include member function cv-qualifiers.
  • A partial specialization of a class member template cannot be added outside of the class definition.

These are no longer missing from standard C++ support.

Section 7.5.1 Using Assembly Language Modules With C/C++ Code[edit]

NOTE: C6600 Stack Alignment[edit]

The C6600 does introduce the 128-bit container type __x128_t as described in the note on page 203 of the C6000 Optimizing Compiler User's Guide (spru187t.pdf). However, the compiler does not enforce 16-byte stack alignment for code compiled for C6600.

The NOTE should be entitled Alignment of __x128_t Type Data Objects (C6600). The pertinent information is as follows:

  • Global data objects of type __x128_t will be aligned to a 16-byte boundary
  • Local data objects of type __x128_t will not necessarily be aligned to a 16-byte boundary as their actual alignment depends on the alignment of the stack pointer (SP) and the SP-relative offset of the local __x128_t type object

For the C6400/C6400+/C6740/C6600 ISAs, the compiler will always align the stack to an 8-byte boundary.

Section 7.5.4 Using Intrinsics to Access Assembly Language Statements[edit]

Table 7-4. TMS320C6400+ and C6740 C/C++ Compiler Intrinsics[edit]

The _dmv() intrinsic description should read: "Places src1 in the 32 MSBs of the long long and src2 in the 32 LSBs of the long long. See also _itoll.

The intrinsic shru2 lacks an underscore. It should read: "unsigned _shru2 (unsigned src1, unsigned src2);"

The _shr2 and _shru2 description should read: "For each 16-bit quantity in src1, the quantity is arithmetically or logically shifted right by src2 number of bits. src1 can contain signed or unsigned values"

Table 7-6. TMS320C67000 C/C++ Intrinsics[edit]

The documentation should note that these intrinsics are also available for C6740 devices.

Section 7.5.8.5[edit]

This section should be numbered 7.5.9.

Section 7.5.8.6[edit]

The "STORE_AMR" in the second element of the list should read "RESTORE_AMR". This section should be numbered 7.5.10.

Section 7.5.11 Floating Point Control Register Side Effects (New)[edit]

When performing floating point operations on a floating-point architecture, status bits in certain control registers may be set. In particular, status bits may be set in the FADCR, FAUCR, and FMCR registers, hereafter referred to as the "floating point control registers". These bits can be set and cleared from C/C++ code by writing to or reading from these registers, as shown in example 6-1. In compiler versions released after July of 2009, the compiler uses the following steps for generating code that accesses any of the floating point control registers.

  1. The floating point control registers become undefined by a function call or a function return. The means the data in the floating point control registers is valid and can be read in C/C++ code until a function call or a function returns.
  2. If the code in a function accesses any of the floating point control registers, the compiler assumes that those registers are live across the function, which means that floating point instructions that may set bits in those floating point control registers cannot be speculatively executed.
  3. If an interrupt service routine modifies any of the bits in a floating point control register, the interrupt service routine should be written to save and restore that floating point control register.

Section 7.6.3[edit]

The following paragraph should be added to the end of the section.

For floating point architectures, you are responsible for handling the floating point control registers FADCR, FAUCR and FMCR. If you are reading bits out of the floating pointer control registers, and if the interrupt service routine (or any called function) performs floating point operations, then the relevant floating point control registers should be saved and restored. No macros are provided for these registers, as simple assignment to and from an unsigned int temporary will suffice.

Section 8.2 The C I/O Functions[edit]

format.h and the format conversion buffer[edit]

The internal routine behind the C I/O functions (such as printf, vsnprintf, snprintf) is _printfi. It will reserve 400 bytes of stack space for a format conversion buffer. This leads to 2 questions:

  • What are the details of this buffer?
  • Can this buffer size be re-defined?

The buffer size is set by the macro FORMAT_CONVERSION_BUFFER in format.h. These items need to be considered before changing the size to a smaller number.

  • Each conversion specified with %xxxx (except %s) has to fit in FORMAT_CONVERSION_BUFSIZE. This means any individual formatted float or integer value, accounting for width and precision specifiers, needs to fit in that buffer. Since the actual value of any representable number should easily fit the main concern is ensuring the width and/or precision size meets the constraints.
  • The length of converted strings using %s are unaffected by any change in FORMAT_CONVERSION_BUFSIZE, so you could specify 'printf("%s value is %d", some_really_long_string, intval)' without a problem.
  • The constraint is for each individual item being converted. For example a format string of "%d blah blah %f blah blah %e blah blah" doesn't have to fit in the buffer, just each converted item specified with %_.
  • For MINIMAL support the macro is set to 32 since under MINIMAL only integer values, without width specifiers, can be printed.
  • There isn't a buffer overrun check.

Also note, the ANSI standard states the conversion buffer should be 4K.

E2e.jpg {{
  1. switchcategory:MultiCore=
  • For technical support on MultiCore devices, please post your questions in the C6000 MultiCore Forum
  • For questions related to the BIOS MultiCore SDK (MCSDK), please use the BIOS Forum

Please post only comments related to the article C6000 Optimizing C/C++ Compiler Errata here.

Keystone=
  • For technical support on MultiCore devices, please post your questions in the C6000 MultiCore Forum
  • For questions related to the BIOS MultiCore SDK (MCSDK), please use the BIOS Forum

Please post only comments related to the article C6000 Optimizing C/C++ Compiler Errata here.

C2000=For technical support on the C2000 please post your questions on The C2000 Forum. Please post only comments about the article C6000 Optimizing C/C++ Compiler Errata here. DaVinci=For technical support on DaVincoplease post your questions on The DaVinci Forum. Please post only comments about the article C6000 Optimizing C/C++ Compiler Errata here. MSP430=For technical support on MSP430 please post your questions on The MSP430 Forum. Please post only comments about the article C6000 Optimizing C/C++ Compiler Errata here. OMAP35x=For technical support on OMAP please post your questions on The OMAP Forum. Please post only comments about the article C6000 Optimizing C/C++ Compiler Errata here. OMAPL1=For technical support on OMAP please post your questions on The OMAP Forum. Please post only comments about the article C6000 Optimizing C/C++ Compiler Errata here. MAVRK=For technical support on MAVRK please post your questions on The MAVRK Toolbox Forum. Please post only comments about the article C6000 Optimizing C/C++ Compiler Errata here. For technical support please post your questions at http://e2e.ti.com. Please post only comments about the article C6000 Optimizing C/C++ Compiler Errata here.

}}

Hyperlink blue.png Links

Amplifiers & Linear
Audio
Broadband RF/IF & Digital Radio
Clocks & Timers
Data Converters

DLP & MEMS
High-Reliability
Interface
Logic
Power Management

Processors

Switches & Multiplexers
Temperature Sensors & Control ICs
Wireless Connectivity