TASKING TriCore VX-Toolchain v2.0r1

RELEASE NOTE


SUMMARY

This release note describes the changes and new features of all TASKING TriCore products since v1.5r2.

The following parts are described:

The main reasons for this release are:


INTRODUCTION TO THE VX-TOOLCHAIN

As you may have noticed the letters VX are added to the name of this new TASKING TriCore toolchain. VX is short for Viper eXperience, and it indicates that this toolchain incorporates the new generation VIPER DSP-C compiler technology. This compiler has been developed in-house by Altium and offers true state-of-the-art code generation. Furthermore specific DSP optimizations have been added, so you will find an improved performance of the compiler in both generated code size and runtime speed.
The compiler offers full compliance with the latest ISO C 1999 standard, for instance the _Bool and long long data types are available and ready for use.
In our strive for being in accordance with the TriCore EABI (Embedded Application Binary Interface), we have introduced the ELF 2.0 object format. This smoothes the integration with many third party products such as RTOS's, software libraries and debuggers. For this purpose the assembler and linker have been redesigned as well. The new linker comes with an enhanced Linker Script Language (LSL) that replaces the obsolete DEscriptive Language For Embedded Environments (DELFEE).
With the upgrade to the Viper technology it turned out to be not possible to maintain full backwards compatibility. However, we have included a migration tool to help you convert a project, originally set up for a previous TriCore toolchain, to one that will build with this new toolchain.
The TASKING TriCore VX-toolset again offers full TriCore 1 and 2 architecture steps and derivatives support. Amongst the latest supported derivatives you will find the tc11ib, tc1910, tc1912 and tc1920b as introduced already in the v1.5r2 and furthermore the tc1766 and tc1796.


EDE

You can navigate through the different option dialogs via the expandable tree view as you are familiar with from other Windows based applications. This new way of presenting the options guarantees that you won't lose the complete overview. Most options available in the new VX-toolset can be set from here.
The dialog box for setting up the registers has changed. From the new representation it is clear which bits are assigned to which fields. You can assign a value to the registers by entering a hexadecimal number or you can make selections via a drop-down list.
The new linker works with a Linker Script Language (LSL). EDE contains a simple GUI for generating LSL files, you can find this GUI in the Linker section under item 'Script File'.


C++ COMPILER

In general the C++ Compiler has remained the same, however the executable name changed from cptri into cptc.

ISO C99 features

The C++ Compiler supports the long long datatype and the restrict keyword as introduced in the ISO C 1999 standard.

Options

In this toolchain you will find a more consequent usage of option names. Short option names have a dash followed by one letter, for example '-s', while long option names have two dashes followed by a description '--long-option-name'. The dash is used as separator between words, while in previous versions of the C++ Compiler the underscore was used.
Example:
   cptri --long_option_name example.cpp  // old invocation, with underscores     
cptc --long-option-name example.cpp // new invocation, with dashes


C COMPILER

The C Compiler executable for TriCore is renamed to ctc. The C Compiler offers full compliance with the latest ISO C 1999 standard. With the upgrade to the Viper technology it turned out to be not possible to maintain full backwards compatibility. This section describes the differences between the VIPER Compiler and compilers as shipped with previous TASKING toolchains. The supplied migration tool, as described in the last section of this release note, handles most of the differences.

ISO C99 features

The compiler complies with the latest ISO C 1999 standard. That means for instance that the boolean (_Bool) and long long data types are available.
The C99 standard introduces a number of new C libraries. You can browse through the library sources as available in the toolchain directory \<proddir>\lib\src to get an impression of the functions currently available. Please be aware that not all new functions may be mentioned in the documentation yet.

Options

Long option names are introduced for all options. You can refer to the reference guide for a complete overview of all available options. The next options as present in previous toolchains have become obsolete.

-Fc The option that enabled 'float' constants is not available anymore
-FPU The option to allow FPU instructions is changed to --fpu-present
-K The option for disabling type checking for K&R functions is not applicable in ISO C99
-O The new compiler has a new set of optimization flags
-WAE The option to treat warning as errors is changed to --warnings-as-errors
-builtin The option to list all builtin functions is not available anymore, since the list has grown too large
-c It is default behavior to allocate strings in code memory
-e It is default behavior to remove output files on errors, also refer to the -k option
-err Send diagnostics to an error file by using --error-file
-wstrict Suppressing strict warnings is not applicable in ISO C99
-z The option to pass pragmas from the command line is not available anymore, you can use option --silicon-bug to specify the silicon bugs

With the -C/--cpu option you define the target processor for which you create your application. Based on the target processor, the compiler includes the register file regcpu.sfr as you are used to. The behavior of the option has changed, since it now automatically detects whether a FPU-unit is present and whether the architecture is a TriCore2 as well. This means that you do not have to specify the options --fpu-present and --is-tricore2 explicitly when one of the supported derivatives is selected.
In the case that you do want to make use of this auto-detect feature, but you want to avoid the inclusion of the TASKING regcpu.sfr file, you can use the option --no-tasking-sfr.

Two other new options --integer-enumeration and --cse-all-addresses have been added.
The option --integer-enumeration causes the compiler to use integers for enumerations, otherwise the compiler uses the smallest suitable integer type.
The option --cse-all-addresses makes all __near and __a(x) addresses available for common subexpressions.

Pragmas

The pragmas asm/asm_noflush/endasm to insert assembly code into C-sources have been deprecated in favor of the GNU-style __asm() intrinsic function.
The pragmas inline/noinline/smartline to control the inlining process of functions are introduced.
The pragmas listinc/nolistinc to expand include files in generated list files are not available anymore.
The pragma stack to force the alternative 'stack' calling convention is no longer supported, use the function qualifier __stackparam instead. The __stackparm qualifier changes the standard calling convention into a convention where all function arguments are passed via the stack.
The pragma section to rename a section, has a slightly different behavior and therefore requires a different usage. For details please refer to the User's Guide.
Two new pragmas are introduced: default_near_size and default_a0_size. With these pragmas you can direct the compiler to access data objects as 'near' objects or as 'a0' objects, depending on their size.

Optimizations

Most of the optimizations as present in previous toolsets are still available, while other optimizations have been added. Probably you will need to specify other flags than you were used to, since the classification of the optimization option has been changed. Due to the new and enhanced set of optimizations you are likely to find an improvement in performance of the compiler in generated code size as well as in runtime speed.

Language extensions

All storage types and qualifiers used to start with one leading underscore, this is changed into two leading underscores. So, in order to specify an integer variable in near memory you declare: 'int __near myint;'.
The _far function storage qualifier is replaced by the __indirect qualifier. In order to qualify a function to be called indirect instead of PC relative or absolute, you need to declare: '__indirect void foo(void);'.
The fractional data types used to be non-saturated by default. These types have been changed to be saturated by default. If you want to stick to the old behavior, you explicitly need to specify this using the __wrap qualifier.

Intrinsic functions

All existing intrinsics, reoccur in this new toolchain. The only difference is that all intrinsics start with a double underscore.
A new group of intrinsics, the so-called 'ETSI' intrinsics, are introduced. These are built-in variants of the basic functions as defined in the ETSI-standard (basic_op.c). Using the intrinsics will help you improve the performance of your application. You need to include the file 'etsimath.h', as can be found in the include directory of the toolchain and remove the files 'basic_op.c' and 'basic_op.h' from your project.

Predefined macros

Predefined macros all follow the same naming convention; macros start and end with a double underscore. For instance the predefined macro _TASKING that identifies the compiler is renamed to __TASKING__.


ASSEMBLER

The TriCore and PCP assembler are kept almost completely backwards compatible, except for the new ELF/DWARF 2.0 output format they produce. Since the ELF standard and the EABI are more restrictive towards section names, the convention for section names and attributes has been changed. Furthermore, the TriCore assembler executable is renamed to astc, the PCP assembler executable name is unchanged aspcp.

Section names

In accordance with the EABI and the ELF standard, TriCore special section names and ELF reserved section names are used. These section names inform the linker where these sections are to be located. If you program in assembly, you should be aware of this convention and should apply the correct section names. For instance the attribute ABS18, that used to specify the data in the section to be direct addressable, has become obsolete. To accomplish the same thing, the section name needs to start with '.zdata'.
Example:
   .SDECL ".mydata", DATA,ABS18 ; old toolchain uses the attribute ABS18	
.SDECL ".zdata.mydata",DATA ; new toolchain uses .zdata section name
For a complete list of available special section names, please refer to the Reference Guide.

Elf/DWARF 2.0 output format

In compliance with the EABI the assembler generates the ELF/DWARF 2.0 output format. The generated output file has the extension '.o', this used to be '.obj'.

Options

Long option names are introduced for all options. You can refer to the reference guide for a complete overview of all available options. The next options as present in previous toolchains have become obsolete.

-FPU The option to allow FPU instructions is changed into --fpu-present
-MMU The option to allow MMU instructions is changed into --mmu-present
-WAE The option to treat warning as errors is changed into --warnings-as-errors
-e It is default behavior to remove output files on errors, also refer to the -k option
-err Send diagnostics to an error file by using --error-file
-hw_only To disable the use of generic instructions, use -OG
-z Use option --silicon-bug to specify the silicon bugs

With the -C/--cpu option you define the target processor for which you create your application. Based on the target processor, the assembler includes the register file regcpu.def as you are used to. The behavior of the option has changed, since it now automatically detects whether a MMU-unit, FPU-unit is present and whether the architecture is a TriCore2 as well. This means that you do not have to specify the options --mmu-present, --fpu-present and --is-tricore2 explicitly when one of the supported derivatives is selected.
In the case that you do want to make use of this auto-detect feature, but you want to avoid the inclusion of the TASKING regcpu.def file, you can use the option --no-tasking-sfr.

Predefined macros

Predefined macros all follow the same naming convention; macros start and end with a double underscore. For instance the predefined macro _TASKING that identifies the assembler is renamed to __TASKING__.

PCP example

An example is added to the product that shows how to setup and make use of the PCP unit. The PCP unit is used as service provider and handles an interrupt. A LED is toggled on the TriCore evaluation board to show the proper working.


LINKER

The linker and locator used to be two separate executables, in the VX-toolset both parts are integrated into one executable ltc. You can still have the new linker generate a 'relocatable' output file by using the incremental linking option '-r' or the '--link-only' option.

LSL

The new linker comes with an enhanced Linker Script Language (LSL) that replaces the obsolete DEscriptive Language For Embedded Environments (DELFEE). In the include.lsl directory of the toolchain you will find a set of LSL files. Each derivative has its own LSL file. The other LSL files are included from this top level entry. You can specify the LSL file by using the -d option, for instance if you are using a tc1775b derivative you need to specify '-dtc1775b.lsl' when invoking the linker/locater. This set of LSL files is there for reference, and these files can remain untouched. There is just one exception; the LSL file 'extmem.lsl', which describes the external memory. Memory sizes and destination offsets as specified in this template file, should be adapted to the real situation. This is application dependent of course. Either you can edit this file directly or you can use EDE as graphical interface to create a project.lsl file, that serves as replacement for the default 'extmem.lsl'.

Elf/DWARF 2.0 output format

In compliance with the EABI the linker accepts input files in ELF/DWARF 2.0 format, and generates ELF/DWARF 2.0 output files. Relocatable files have the extension .out, while absolute output files have the extension .elf. For compatibility reasons the linker is able to produce IEEE-695 output files. The penalty for using this output format, is that debug information as present in ELF/DWARF objects is stripped off, since it is not possible to convert debug information from one format to an other.

Options

Long option names are introduced for all options. You can refer to the reference guide for a complete overview of all available options. The next options as present in previous toolchains have become obsolete.

-C To link case insensitive use --case-insensitive
-N The option to generate an external part or turn off overlaying is not available anymore
-O The option to set a default base name for the map file is not available anymore, use the option --map-file[=<file>] to specify the required name of the map file
-S The option to generate a specific space is not available anymore
-WAE The option to treat warning as errors is changed to --warnings-as-errors
-c To generate a call graph use the -mc option, the call graph is printed in the map file
-e It is default behavior to remove output files on errors, also refer to the -k option
-em To define a preprocessor macro use -D
-err Send diagnostics to an error file by using --error-file
-f Specify the output format by using -c and/or -F
-p The option to make a proposal for a software part is obsolete
-r The option to suppress undefined symbol diagnostics is obsolete, the current -r option is to link incrementally
-u The option to specify a symbol as unresolved external is changed to -e
-w The option to suppress warnings above a certain level is replaced by an option -w to suppress specific warning numbers

Environment variables

The name of the environment variable to specify an additional search path for system libraries is changed from 'CTRILIB' in 'LTCLIBTC1V1.2', 'LTCLIBTC1V1.2' or 'LTCLIBTC2'. The linker uses one of the environment variables, depending on the specified 'architecture' in the LSL file.


UTILITIES

The utilities are adapted in order to support the new compiler, assembler and linker, their options and the new ELF/DWARF 2.0 output format. Please refer to the reference manual for the available options.

Archiver

The archiver artc now accepts object files in ELF/DWARF 2.0 format only.

Control program

The control program cctc supports the new compiler, assembler and linker and their options. If you work from the command line, you preferably use the control program instead of invoking the tools separately.

Make utility

The make utility mktc knows how to handle files with extension '.o' and '.elf'.

Object dumper

The object dumper prtc is able to dump object files in ELF/DWARF 2.0 format.


CROSSVIEW PRO

In general CrossView Pro has not changed a lot, the usage and the options are still the same.

ELF/DWARF 2.0 format

CrossView Pro has been adapted so that it is able to read absolute files in the ELF/DWARF 2.0 format. It is not able to handle IEEE-695 objects anymore.

Debugging inline functions

The debug information of inline functions has been improved which enables you to debug inline functions, when running the CrossView Pro debugger.

New derivatives supported

The TriCore boards of Infineon for the latest available TriCore derivatives: tc11ib, tc1910, tc1912 and tc1920b are supported, as well as all the older boards.


MIGRATION TOOL

The migration tool cnv2vx (convert-to-VX) is there to help you convert an existing project, set up for a previous toolchain to a project that builds with the VX-toolset. The migration tool deals with all incompatibilities as described in the previous sections. Note however that existing DELFEE files are not converted. If you have made any changes in the DELFEE files, you need to take over these changes in the LSL files manually.
You can find the conversion tool in the cnv2vx directory in the product tree. In this directory you will find a readme that describes how to use the tool.


Copyright 2003 Altium BV