NOTICE: The Processors Wiki will End-of-Life in December of 2020. It is recommended to download any files or other content you may need that are hosted on The site is now set to read only.

MCU Compiler v17

From Texas Instruments Wiki
Jump to: navigation, search

Available as of v18.1.0.LTS

ARM/MSP430: C++ 2014 RTS Support

As of v18.1.0.LTS, the compiler uses the C++14 version of the C++ standard. Previously, C++03 was used. See the C++ Standard ISO/IEC 14882:2014. For a description of unsupported C++14 features, see Section 5.2 of the "TI ARM Optimizing Compiler User's Guide".

The move to C++14 will break ABI compatibility with previous C++ RTS releases. Attempting to link old C++ object code with the new RTS will result in a link-time error. Suppressing this error will likely result in undefined symbols or undefined behavior during execution.

C ABI compatibility will not be affected by this change.

In most cases, recompiling old source code with the new RTS should be safe. However, due to the changes made in the language, some constructs will result in syntax errors. Some common issues include:

  • Macro expansion immediately adjacent to string literals may fail due to the inclusion of new string literals and literal suffixes.
  Ex: u8"def" will fail to compile if 'u8' is a macro
      "def"_x will fail to compile if '_x' is a macro
  • New keywords: alignas, alignof, char16_t, char32_t, constexpr, decltype, noexcept, nullptr, static_assert, and thread_local
  • The auto keyword has been repurposed and is no longer a valid storage class specifier. Similarly, the register keyword has been deprecated and will be removed in the future.

A full list can be found in Appendix C, section 2 of the C++14 standard.

Available as of v17.9.0.STS

The v17.9.0.STS release contains several fixes to defects that have been reported against previous versions of the tools. Development of new features is still in progress and some of these efforts will be completed for the LTS release.

ARM: Support for ARM C Language Extensions (ACLE)

Beginning with the ARM CGT v17.9.0.STS release, support for ARM C Language Extensions (ACLE) as specified in the ACLE Release 2.0 document (Document number: IHI 0053C, Date of Issue: 09/05/2014) has been added for the applicable processor variants that are supported in the ARM CGT. This includes support for new ACLE attributes, intrinsics, and pre-defined symbols as detailed in the sub-sections below. See readme.txt for details.

CLA code size improvements

Improvements in instruction scheduling have reduced code size 1 to 2% for generated CLA code. The improvements are due to better flexibility in scheduling of CLA auxiliary register usage as well as improved modeling of the CLA pipeline's write-followed-by-read restriction especially around branches and calls. These improvements are enabled by default during code generation.

C++ ABI Compatibility

This release contains the first planned updates in preparation for the support of C++14 (International Standard ISO/IEC 14882:2014(E)). As part of this update, it is necessary to make changes which might cause errors when building C++ projects containing C++ object files compiled with older versions of the compiler.

These errors will usually include linktime errors involving undefined symbols. If you see undefined symbol errors during a link, pass the "--no_demangle" option to the compiler. If the undefined symbol's name starts with _Z or _ZVT, then it's possible that there is a C++ object file or library built with an older version of the tools being used. These will need to be compiled with the v17.9.0.STS tools to work properly.

Available as of v17.6.0.STS

The v17.6.0.STS release contains several fixes to defects that have been reported against previous versions of the tools. Development of new features is still in progress and some of these efforts will be completed for the next STS release, 17.9.0.STS.

MSP430: IAR Compatibility: __cc_rom calling convention

The TI MSP430 compiler requires that a function which returns a signed char value in the return register sign extend the return value to 16-bits in that register before returning to the caller. The IAR compiler does not adhere to this requirement. To address this issue, the TI MSP430 compiler will recognize a call to a function that has been annotated with the __cc_rom calling convention attribute and that returns a signed char type return value, and then sign extend the return value from such a function to 16-bits before that value is used elsewhere in the caller function.

Available as of v17.3.0.STS

C2000/CLA: Optimization of volatile bitfield assignments

Prior to this release, asignments to volatile bitfields would follow the read, modify, write methodology, even when such an operation is not needed. Consider the following code segment:

short a;
struct str16 {
   short x:16;
volatile struct str16 str16_vol;

void foo(void)
   str16_vol.x = a;

Prior to this optimization, str16_vol.x would be read before being assigned to, resulting in the C2000 assembly:

        MOV       AL,@_str16_vol
        MOV       AL,@_a
        MOV       @_str16_vol,AL

The initial MOV is unnecessary. With this release, such a move will not be generated on either C2000 or CLA.

CLA: Prefer direct addressing with --cla_support=cla[12]

When accessing and object multiple times in succession, earlier versions of the compiler would generate inefficient indirect addressing operations. For example, the following code:

struct { short x; short y; } dst_struct;
dst_struct.y = 0;

Might generate the following assembly:

        MMOVI16   MAR1,#_dst_struct
        MMOVZ16   MR0,#0
        MMOV16    *MAR1+[#1],MR0

In this release, the following assembly will be genereated instead:

        MMOVZ16   MR0,#0
        MMOV16    @_dst_struct+1,MR0

IAR Compatibility: __cc_rom calling convention

Fixed an issue where using the __cc_rom calling convention with parameters of pointer type could result in code that passed the pointer in the wrong register. For example:

typedef struct { uint8_t a; uint_8 b; } str_t;
extern __cc_rom void func(uint16_t, str_t *);
str_t my_str = {0, 0};
func(0, &my_str);

The address of 'my_str' would be passed in R14 erroneously, instead of R13.

Available as of v16.12.0.STS

ROM Calling Convention (MSP)

A new function attribute, call_conv, allows specifing calling convention. Additionally, there is a new calling convention for ROM use cases.

The new call_conv attribute can be used to specify the calling convention for function calls. This is intended for allowing IAR and TI MSP430 compilers to link against the same ROM image if it was generated using the new cc_rom calling convention.

Currently the implementation only supports linking against ROM images built with IAR’s MSP430 compiler using their ROM calling convention implementation. The TI MSP430 Compiler currently does not support generating cc_rom ROM images.

The new attribute can be applied to functions, function pointers, and function typedefs.

The attribute is applied to a function with GCC attribute syntax, as follows:


The new attribute accepts "cc_rom" or "cc_norm" (the default calling convention).

See the MSP430 Optimizing C/C++ Compiler User's Guide or below article for more details:

Improved stack usage with inline functions

The new compiler improves stack usage by sharing aggregate data originally defined in inline functions. Example:

struct ARGS { int f1,f2,f3,f4,f5; };

static inline void func1()
   struct ARGS a = {1, 2, 3, 4, 5};

static inline void func2()
   struct ARGS b = {1, 2, 3, 4, 5};

void func3()

In previous compilers, if func1 and func2 are inlined, the structs a and b would not share the same stack location. This version of the compiler will now share stack memory for local aggregates defined in inline functions.