2 OVERVIEW

This chapter contains the following sections:

Introduction to C++ Compiler

Development Structure
The Prelinker Phase
The Muncher Phase

Environment Variables

File Extensions

2.1 Introduction to C++ Compiler

This manual provides a functional description of the TASKING TriCore C++ Compiler. This manual uses cptc (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 cptc is TriCore C, which can be translated with the C compiler ctc .

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 (.o) and libraries (.a) and files with extension .out and .lsl are recognized as linker input files. 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.

2.2 Development Structure

The next figure explains the relationship between the different parts of the TASKING TriCore toolchain:

Figure 2-1: Development flow

2.2.1 The Prelinker Phase

The C++ compiler provides a complete prototype 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.

2.2.2 The Muncher Phase

The C++ muncher implements global initialization and termination code.

The muncher accepts the output of the linker as its input file. 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.

2.3 Environment Variables

This section contains an overview of the environment variables used by the TriCore toolchain.

Environment Variable Description
ASTCINC With this variable you specify one or more additional directories in which the assembler astc looks for include files. The assembler first looks in these directories, then always looks in the default c:\ctc\include directory.
ASPCPINC With this variable you specify one or more additional directories in which the assembler aspcp looks for include files. The assembler first looks in these directories, then always looks in the default c:\ctc\include directory.
CTCINC With this variable you specify one or more additional directories in which the C compiler ctc looks for include files. The compiler first looks in these directories, then always looks in the default c:\ctc\include directory.
CCTCBIN With this variable you specify the directory in which the control program cctc looks for the executable tools. The path you specify here should match the path that you specified for the PATH variable.
CCTCOPT With this variable you specify options and/or arguments to each invocation of the control program cctc. The control program processes these arguments before the command line arguments.
LM_LICENSE_FILE With this variable you specify the location of the license data file. You only need to specify this variable if your host uses the FLEXlm licence manager.
LTCLIB With this variable you specify one or more alternative directories in which the linker ltc looks for library files. The linker first looks in these directories, then always looks in the default c:\ctc\lib directory.
PATH With this variable you specify the directory in which the executables reside (default: product\bin). This allows you to call the executables when you are not in the bin directory.
TMPDIR With this variable you specify the location where programs can create temporary files.

Table 2-1: Environment variables

2.4 File Extensions

For compatibility with future TASKING Cross-Software the following extensions are suggested:

Source files:

.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-written assembly source file, input for the assembler

.lsl linker script file, input for the linker

.i control file with defines for linker script file, input for the linker

Generated source files:

.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

Object files:

.o relocatable ELF/DWARF object file generated by the assembler, input for the linker

.a object library file

.out relocatable linker output file

.abs absolute IEEE-695 output file from the linker

.elf absolute ELF/DWARF output file from the linker

.hex absolute Intel Hex output file from the linker

.sre absolute Motorola S-record output file from the linker

List files:

.lst assembler list file

.map linker map file

Error List files:

.err compiler error messages file

.ers assembler error messages file

.elk linker error messages file


Copyright © 2003 Altium BV