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:
- Redesign of the compiler, assembler and linker
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.
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'.
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
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__.
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.
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.
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.
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.
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