This chapter contains the following sections:
Development Structure
The Prelinker Phase
The Muncher Phase
This manual provides a functional description of the TriCore C++ Compiler. This manual uses cptri (the name of the binary) as a shorthand notation for "TASKING TriCore C++ Compiler". You should be familiar with the C++ language and with the ANSI/ISO C language.
The C++ compiler can be seen as a preprocessor or front end which accepts C++ source files or sources using C++ language features. The output generated by cptri is TriCore C, which can be translated with the C compiler ctri .
The C++ compiler is part of a complete toolchain. For details about the C compiler see the "TASKING TriCore C Compiler User's Guide".
The C++ compiler is normally invoked via the control program which is part of the toolchain. The control program facilitates the invocation of various components of the toolchain. The control program recognizes several filename extensions. C++ source files (.cc, .cxx, .cpp or .c with the -c++ option) are passed to the C++ compiler. C source files (.c) are passed to the compiler. Assembly sources (.asm or .src) are passed to the assembler. Relocatable object files (.obj) and libraries (.a) are recognized as linker input files. Files with extension .out and .dsc are treated as locator input files. Everything else is considered an object file and is passed to the linker. The control program supports options to stop at any stage in the compilation process and has options to produce and retain intermediate files.
The C++ compiler accepts the C++ language of the ISO/IEC 14882:1998 C++ standard, with some minor exceptions documented in the next chapter. It also accepts embedded C++ language extensions.
The C++ compiler does no optimization. Its goal is to produce quickly a complete and clean parsed form of the source program, and to diagnose errors. It does complete error checking, produces clear error messages (including the position of the error within the source line), and avoids cascading of errors. It also tries to avoid seeming overly finicky to a knowledgeable C or C++ programmer.
The next figure explains the relationship between the different parts of the TASKING TriCore toolchain:
Figure 2-1: Development flow
The C++ compiler provides a complete implementation of an automatic instantiation mechanism. The automatic instantiation mechanism is a "linker feedback" mechanism. It works by providing additional information in the object file that is used by a "prelinker" to determine which template entities require instantiation so that the program can be linked successfully. Unlike most aspects of the C++ compiler the automatic instantiation mechanism is, by its nature, dependent on certain operating system and object file format properties. In particular, the prelinker is a separate program that accesses information about the symbols defined in object files.
At the end of each compilation, the C++ compiler determines whether any template entities were referenced in the translation unit. If so, an "instantiation information" file is created, referred to for convenience as a .ii file. If no template entities were referenced in the translation unit, the .ii file will not be created and any existing file will be removed. If an error occurs during compilation, the state of the .ii file is unchanged.
Once a complete set of object files has been generated, including the appropriate flags, the prelinker is invoked to determine whether any new instantiations are required or if any existing instantiations are no longer required. The command line arguments to the prelinker include a list of input files to be analyzed. The input files are the object files and libraries that constitute the application. The prelinker begins by looking for instantiation information files for each of the object files. If no instantiation information files are present, the prelinker concludes that no further action is required.
If there are instantiation information files, the prelinker reads the current instantiation list from each information file. The instantiation list contains the list of instantiations assigned to a given source file by a previous invocation of the prelinker. The prelinker produces a list of the global symbols that are referenced or defined by each of the input files. The prelinker then simulates a link operation to determine which symbols must be defined for the application to link successfully.
When the link simulation has been completed, the prelinker processes each input file to determine whether any new instantiations should be assigned to the input file or if any existing instantiations should be removed. The prelinker goes through the current instantiation list from the instantiation information file to determine whether any of the existing instantiations are no longer needed. An instantiation may be no longer needed because the template entity is no longer referenced by the program or because a user supplied specialization has been provided. If the instantiation is no longer needed, it is removed from the list (internally; the file will be updated later) and the file is flagged as requiring recompilation.
The prelinker then examines any symbols referenced by the input file. The responsibility for generating an instantiation of a given entity that has not already been defined is assigned to the first file that is capable of generating that instantiation.
Once all of the assignments have been updated, the prelinker once again goes through the list of object files. For each, if the corresponding instantiation information file must be updated, the new file is written. Only source files whose corresponding .ii file has been modified will be recompiled.
At this point each .ii file contains the information needed to recompile the source file and a list of instantiations assigned to the source file, in the form of mangled function and static data member names.
If an error occurs during a recompilation, the prelinker exits without updating the remaining information files and without attempting any additional compilations.
If all recompilations complete without error, the prelink process is repeated, since an instantiation can produce the demand for another instantiation. This prelink cycle (finding uninstantiated templates, updating the appropriate .ii files, and dispatching recompilations) continues until no further recompilations are required.
When the prelinker is finished, the linker is invoked. Note that simply because the prelinker completes successfully does not assure that the linker will not detect errors. Unresolvable template references and other linker errors will not be diagnosed by the prelinker.
The C++ muncher implements global initialization and termination code.
The muncher takes the output of the linker as its input file and looks for names beginning with prefixes such as __sti__ or __std__, those being, respectively, initialization and termination routines to be called at run-time. It generates a C program that defines a data structure containing a list of pointers to the initialization and termination routines. This generated program is then compiled and linked in with the executable. The data structure is consulted at run-time by startup code invoked from _main, and the routines on the list are invoked at the appropriate times.
This section contains an overview of the environment variables used by the TriCore toolchain.
Environment Variable | Description |
ASTRIINC | Specifies an alternative path for include files for the assembler. |
CTRIINC | Specifies an alternative path for #include files for the C compiler ctri. |
CTRILIB | Specifies a path to search for library files used by the linker lktri. |
CCTRIBIN | When this variable is set, the control program, cctri, prepends the directory specified by this variable to the names of the tools invoked. |
CCTRIOPT | Specifies extra options and/or arguments to each invocation of cctri. The control program processes the arguments from this variable before the command line arguments. |
CPTRIINC | Specifies an alternative path for #include files for the C++ compiler cptri. |
LM_LICENSE_FILE | Identifies the location of the license data file. Only needed for hosts that need the FLEXlm license manager. |
PATH | Specifies the search path for your executables. |
TMPDIR | Specifies an alternative directory where programs can create temporary files. |
Table 2-1: Environment variables
For compatibility with future TASKING Cross-Software the following extensions are suggested:
.cc C++ source file, input for C++ compiler
.cxx C++ source file, input for C++ compiler
.cpp C++ source file, input for C++ compiler
.c C source file, input for C compiler (or for C++ compiler if you use the -c++ option of the control program)
.asm hand coded assembly source file, input for the assembler
.dsc description file, input for linker/locator
.ic temporary C source file generated by the C++ compiler, input for the C compiler
.src assembly source file generated by the C compiler, input for the assembler
.pr output file generated by the object reader, input for the C++ muncher
.mc C source file generated by the C++ muncher, input for the C compiler
.ms assembly source file generated by the C compiler, input for the assembler
.mo relocatable IEEE-695 object file generated by the assembler, input for the linker
.obj relocatable IEEE-695 object file generated by the assembler, input for the linker
.a object library file
.out relocatable linker output file
.abs absolute locator output file, IEEE-695 object file
.hex absolute Intel Hex output file from the locator
.sre absolute Motorola S-record output file from the locator
.lst assembler list file
.cal C function call graph file, output from the linker
.lnl linker map file
.map locator map file