Please note as of Wednesday, August 15th, 2018 this wiki has been set to read only. If you are a TI Employee and require Edit ability please contact x0211426 from the company directory.
Compiler Version Numbers and What They Mean
When you see a compiler version number like 6.1.11 or 15.12.0.LTS, what does that mean?
- 1 The CCS version is not related
- 2 Interpreting the compiler version number
- 3 Compatibility between different compiler versions
- 4 The compiler version numbering scheme is non-linear
- 5 Choosing a compiler version
- 6 FAQ
The compiler tools have a version number that is not related to the version of Code Composer Studio. A single copy of CCS might have several different versions of the compiler installed. If you are asked for the compiler version number, it's important that you report that; the CCS version is not sufficient.
Interpreting the compiler version number
Two version numbering schemes are in use. Newer release numbers have four parts, and always end with STS or LTS. Older release numbers have three parts made up of only numbers.
Releases of ARM, MSP, and C28x compilers since 2015
The microcontroller compiler releases are numbered based on the year and month of release. The compiler version numbers are of the form YY.MM.P.STS or YY.MM.P.LTS.
- YY: last two digits of the year
- MM: month
- P: patch
- STS: short term support
- LTS: long term support
YY.MM is the month of the release
The first two numbers are the year and approximate month of the first release. Examples are 15.3 and 15.6, representing March 2015 and June 2015. Releases that vary in YY.MM can contain very different features or capability. The farther apart in time the releases, the more different the releases.
P is the patch level
The P digit is a patch number. P begins with 0, and increases by 1 for each subsequent release. If the only difference between two version numbers is P, then the only difference between the releases is bug fixes. The text file DefectHistory.txt, located in the root directory of the compiler installation, lists which bugs are fixed and known in that release. You generally want P to be as high as possible.
STS or LTS
STS is an acronym for Short Term Support. LTS is an acronym for Long Term Support. See also https://en.wikipedia.org/wiki/Long-term_support
STS releases, with rare exceptions, are available about 3 months. Thus STS releases usually have a P of 0. Examples include 15.3.0.STS and 15.6.0.STS. If you experience a problem while using an STS release, your choices are to workaround it, revert to an earlier release, or wait for the next STS. The next STS will fix your problem, but also introduces new features or improvements. An STS release has two purposes. One purpose is to get new features and capability out to the field quickly. The other purpose is to build up, through a series of related STS releases, the full feature set of an eventual LTS release. These advantages are countered by an increase in risk that new features or capability may cause problems.
LTS releases are available for one to two years. Of course the first LTS release has P of 0. But subsequent releases with P higher than 0 are common. Note that you might see a release version number like 15.12.10.LTS appear in 2017. Even though the current year is 2017, the first release occurred in December of 2015. The purpose of LTS releases is to establish a series of releases that changes only in bug fixes over time, and thus becomes ever more stable.
Compiler version numbers are of the form X.Y.P, where a change in each position indicates the type and/or degree of changes that that compiler version has from any preceding version. You can use the differences to determine what sort of changes in features and bugs you will experience when you upgrade from one version to another.
P is the patch level
When only bug fixes (and no new features) are made to a release, the P digit is incremented. If the only difference between version numbers is P, then only bug fixes have been applied. See the README and/or ReleaseNotes for information on which defects have been fixed (and possibly any new defects that have been identified).
In general, you want your P number to be as high as possible since that means you have the greatest number of bugs fixed. Over time, subsequent releases with only changes in the P digit will have fewer and fewer bugs as they are found and fixed because no other changes are being made to that release stream (e.g. no new features or functionality).
... is available in slides 4-7 of the presentation on C6x Code Generation Tools v6.1
Compatibility between different compiler versions
Code generated using older compiler versions is almost always compatible with newer compiler versions. The compiler team tries not to invalidate ABIs or APIs without good reason. That said, sometimes features are indeed removed or changed.
The most important rule is that when compiling a program, you must use a version of the linker that is at least as recent as the most recent compiler version used to compile any object file in the application, and you must use the version of the RTS that exactly matches the version of the linker. All other combinations are not supported.
The compiler version numbers give you a relative idea of how likely they are to be compatible with each other. The closer the numbers, the closer to exact compatibility.
Consider "new style" version numbers of the form YY.MM.P. The P digit is a patch number. If the only difference between two version numbers is P, then the only difference between the releases is bug fixes. Thus, it is guaranteed that when only P differs, the compiler versions are exactly compatible (unless some severe bug requires a change in an ABI/API, which is very unlikely. If this happens, it will be documented.)
Consider "old style" version numbers of the form X.Y.P. The X digit, the "major" number, represents a substantial change of some sort. Compatibility across versions with different X numbers is not assured. (But it's not a guarantee of incompatibility either.) Build options may be provided to preserve compatibility, but not always. The Y digit, the "minor" number, means there is still ABI-level (or object level) compatibility. In addition to bug fixes, new features are typically added. Code which uses the new features is probably not compatible with previous versions that lack those features. The P digit, the "patch" digit, is exactly like the P digit in the "new style" above.
When comparing an X.Y.P number to a YY.MM.P number, you can treat the pair X.Y much like the pair YY.MM
Two releases with the same X.Y numbers are fully compatible and there should be no trouble linking the object files together or using the same options on both versions.
The compiler version numbering scheme is non-linear
Major compiler versions are numbered in numerically ascending order, but patch releases are numbered as patches of major versions, which creates a tree of versions. For example, for ARM, the major releases are
|5.2.0 →||15.9.0.STS →||15.12.0.LTS →||16.3.0.STS →||16.6.0.STS|
However, each of those is also the head of a release stream where only bug fixes are applied, and the version number only differs in the P digit:
|5.2.0 →||15.9.0.STS →||15.12.0.LTS →||16.3.0.STS →||16.6.0.STS|
Consider version 15.12.3.LTS; it was actually released in June 2016, which is after 16.3.0.STS was released, but because it was merely a patch release of 15.12.P.LTS, it gets a version number matching its major version.
Choosing a compiler version
TI usually maintains multiple active release streams for a given ISA, ranging from older to newer streams. Bug fixes are added to every active stream simultaneously. New features are added only to the most recent stream; by avoiding non-bug-fix changes to older streams, those streams remain stable and we have more and more confidence that they are stable. Newer streams have more features, but are not yet proven as stable as the older active streams. The customer must decide whether proven stability or more features is a better fit for their application.
Here are some basic rules of thumb:
- If you are starting a new project, favor the latest LTS version
- If you are selecting a compiler version for a project that must stay with one compiler version for a very long time, do not select an STS version
- If you have an application that seems to be working fine and you're getting the performance you need, consider staying with that compiler version.
- If you suffer from a compiler bug, first get the most recent patch fix version for the same major version. If that doesn't help, get the most recent major version to see if the bug has been fixed. If it isn't, post to the compiler forum
- You should probably only consider STS versions for evaluation or development, or if the STS version is the only version that supports a feature you need. Once an LTS version becomes available, you should strongly consider switching to the LTS version.
- Whatever major version you select, use the most recent patch fix version available
What are the differences between a compiler that has an "old style number" versus one with a "new style number"?
Just the date of release. It's just a change in the version numbering policy. Think of the transition to the new numbering style as a change in the X digit.
Do the newer releases use a different code base than the older releases?
No, it's the same code base.