2 OVERVIEW

This chapter contains the following sections:

Introduction to TriCore C Cross-Compiler

Product Definition

General Implementation
Compiler Phases
Frontend Optimizations
Backend Optimizations

Compiler Structure

Environment Variables

Sample Session
Using EDE
Using the Control Program
Using the Makefile

2.1 Introduction to TriCore C Cross-Compiler

This manual provides a functional description of the TASKING TriCore C Cross-Compiler. This manual uses ctri (the name of the binary) as a shorthand notation for "TASKING TriCore C Compiler".

TASKING offers a complete toolchain for the Siemens TriCore family of processors. 'TriCore' is used as a shorthand notation for the TriCore family of processors and their derivatives.

The TASKING TriCore C compiler accepts source programs written in ANSI C and translates these into TriCore assembly source code files. The compiler accepts language extensions to improve code performance and to allow the use of typical TriCore architectural provisions efficiently at the C level. The compiler is ANSI C compatible and consists of three major parts; the preprocessor, the C frontend and the associated TriCore backend or code generator. These are all integrated into a single program to avoid the need of intermediate files, thus speeding up the compilation process. It also simplifies the implementation of joint frontend-backend optimization strategies and preprocessor pragmas. This effectively makes the compiler a one pass compiler, with minimum file I/O overhead.

The compiler processes one C function at a time, until the entire source module has been read. The function is parsed, checked on semantic correctness and then transformed into an intermediate code tree that is stored in memory. Code optimizations are performed during the construction of the intermediate code, and are also applied when the complete function has been processed. The latter are often referred to as global optimizations.

ctri generates assembly source code using the TriCore assembly language specification, you must assemble this code with the TASKING TriCore Cross-Assembler. This manual uses astri as a shorthand notation for "TASKING TriCore Cross-Assembler".

You can link the generated object with other objects and libraries using the TASKING lktri TriCore linker. In this manual we use lktri as a shorthand notation for "TASKING lktri TriCore linker". You can locate the linked object to a complete application using the TASKING lctri TriCore locator. In this manual we use lctri as a shorthand notation for "TASKING lctri TriCore locator".

The program cctri is a control program. The control program facilitates the invocation of various components of the TriCore toolchain. cctri recognizes several filename extensions. C source files (.c) are passed to the compiler. Assembly sources (.asm and .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. The control program supports options to stop at any stage in the compilation process and has options to produce and retain intermediate files.

You can debug the software written in C with the TASKING CrossView Pro high-level language debugger. A list of supported platforms and emulators is available from TASKING.

2.2 Product Definition

Name:

TASKING TriCore C CroSs-Compiler

Ordering Code:

TK060002

Target Assembler:

TASKING TriCore Cross-Assembler
TK060000 (included in TK060002)

Target Debugger:

TASKING TriCore CrossView Pro debugger (TK060043)

Target Processors:

All TriCore derivatives. Special function registers can be accessed by means of a user-definable register file.

2.3 General Implementation

This section describes the different phases of the compiler and the target independent optimizations.

2.3.1 Compiler Phases

During the compilation of a C program, a number of phases can be identified. These phases are divided into two groups, referred to as frontend and backend.

frontend:

The preprocessor phase:

The scanner phase:

The parser phase:

The frontend optimization phase:

backend:

The backend optimization phase:

The code generator phase:

The peephole optimizer / pipeline scheduler phase:

All phases (of both frontend and backend) of the compiler are combined into one program. The compiler does not use intermediate files for communication between the different phases of compilation. The backend part is not called for each C statement, but starts after a complete C function has been processed by the frontend (in memory), thus allowing more optimization. The compiler only requires one pass over the input file, resulting in relatively fast compilation.

2.3.2 Frontend Optimizations

The command line option -O controls the amount of optimization applied on the C source. Within a source file, the pragma #pragma optimize sets the optimization level of the compiler. Using the pragma, certain optimizations can be switched on or off for a particular part of the program. Several optimizations cannot be controlled individually. e.g., constant folding will always be done.

The compiler performs the following optimizations on the intermediate code. They are independent of the target processor and the code generation strategy:

Constant folding

Expressions only involving constants are replaced by their result. E.g. 1+5*3) is replaced by the value 16.

Expression rearrangement

Expressions are rearranged to allow more constant folding. E.g. 5+ (x-3) is transformed into x + (5-3), which can be folded and will result in x+2.

Expression simplification

As an example, multiplication by 0 or 1 and additions or subtractions of 0 are removed. Such useless expressions can be introduced by macros, or by the compiler itself (e.g., array subscription).

Logical expression optimization

Expressions involving '&&', '||' and '!' are interpreted and translated into a series of conditional jumps.

Loop rotation

With for and while loops, the expression is evaluated once at the 'top' and then at the 'bottom' of the loop. This optimization speeds up execution, and it could also save code in some cases.

Control flow optimization

By reversing jump conditions and moving code, the number of jump instructions is minimized. This reduces both the code size and the execution time.

Jump chaining

A conditional or unconditional jump to a label which is immediately followed by an unconditional jump may be replaced by a jump to the destination label of the second jump. This optimization does not save code, but speeds up execution.

Remove useless jumps

An unconditional jump to a label directly following the jump is removed. A conditional jump to such a label is replaced by an evaluation of the jump condition. The evaluation is necessary because it may have side effects.

Conditional jump reversal

A conditional jump over an unconditional jump is transformed into one conditional jump with the jump condition reversed. This reduces both the code size and the execution time.

Constant/copy propagation

A reference to a variable with known contents is replaced by those contents.

Common subexpression elimination

The compiler has the ability to detect repeated uses of the same (sub-) expression. Such a "common" expression may be temporarily saved to avoid recomputation. This method is called common subexpression elimination, abbreviated CSE.

Invariant code motion

Invariant code can be moved out of a loop.

Subscript strength reduction

Expressions involving a loop index variable can be reduced in strength.

Dead code elimination

Unreachable code can be removed from the intermediate code without affecting the program. However, the compiler generates a warning message, because the unreachable code may be the result of a coding error.

Dead assignment elimination

Removal of assignments to objects that are not used afterwards.

Dead storage elimination

Remove unused storage.

Loop unrolling

Eliminates short loops by replacing them with a number of copies.

In-line functions

In-line functions are supported. The overhead caused by a function call is removed.

Sharing of string literals and floating point constants

String literals and floating point constants are put in ROM memory. The compiler overlays identical strings (within the same module) and let them share the same space, thus saving ROM space. Likewise identical floating point constants are overlaid and allocated only once.

2.3.3 Backend Optimizations

The following optimizations are target dependent and are therefore performed by the backend.

Peephole optimizations

The generated assembly code is improved by replacing instruction sequences by equivalent but faster and/or shorter sequences, or by deleting unnecessary instructions.

Leaf function handling

Leaf functions (function not calling other functions), are handled specially with respect to stack frame building.

Tail recursion elimination

Replace a recursion statement to branch to the beginning of the statement.

2.4 Compiler Structure

If you want to build a TriCore application you need to invoke the following programs directly, or via the control program:

You can directly load the output file of the locator with extension .abs into the CrossView Pro debugger.

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

Figure 2-1: TriCore development flow

The program cctri is a so-called control program, which facilitates the invocation of various components of the TriCore toolchain. C source programs are compiled by the compiler, assembly source files are passed to the assembler. A C preprocessor program is available as an integrated part of the C compiler. The control program recognizes the file extensions .a and .obj as input files for the linker. The control program passes files with extensions .out and .dsc to the locator. All other files are considered to be object files and are passed to the linker. The control program has options to suppress the locating stage (-cl), the linker stage (-c) or the assembler stage (-cs).

Optionally the locator, lctri produces output files in Motorola S-record format or Intel Hex format. The default output format is IEEE-695.

Normally, the control program removes intermediate compilation results, as soon as the next phase completes successfully. If you want to retain all intermediate files, the option -tmp prevents removal of these files.

For a description of all utilities available and the possible output formats of the locator, see the TriCore Cross-Assembler User's Guide.

The name of the TriCore CrossView Pro Debugger is xfwtri. For more information check the TriCore CrossView Pro Debugger User's Guide.

2.5 Environment Variables

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.
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. Used by ctri, cctri, astri, lktri, lctri, artri.

Table 2-1: Environment variables

2.6 Sample Session

The subdirectory dhry in the examples subdirectory contains a demo program for the TriCore toolchain.

In order to debug your programs, you will have to compile, assemble, link and locate them for debugging using the TASKING TriCore tools. You can do this with one call to the control program or you can use EDE, the Embedded Development Environment (which uses a project file and a makefile) or you can call the makefile from the command line.

2.6.1 Using EDE

EDE stands for "Embedded Development Environment" and is the MS-Windows oriented Integrated Development Environment you can use with your TASKING toolchain to design and develop your application.

To use EDE on the dhry demo program in the subdirectory dhry in the examples subdirectory of the TriCore product tree follow the steps below. This procedure is outlined as a guide for you to build your own executables for debugging.

How to Start EDE

You can launch EDE by double-clicking on the EDE shortcut on your desktop.

The EDE screen provides you with a menu bar, a toolbar (command buttons) and one or more windows (for example, for source files), a status bar and numerous dialog boxes.

How to Select a Toolchain

EDE supports all the TASKING toolchains. When you first start EDE, the correct toolchain of the product you purchased is selected and displayed in the title of the EDE desktop window.

If you have more than one TASKING product installed and you want to change toolchains, do the following::

1. From the Project menu, select Select Toolchain...

The Select Toolchain dialog appears.

2. Select the toolchain you want. You can do this by clicking on a toolchain in the Toolchains list box and click OK.

If no toolchains are present, use the Browse... or Scan Disk... button to search for a toolchain directory. Use the Browse... button if you know the installation directory of another TASKING product. Use the Scan Disk... button to search for all TASKING products present on a specific drive. Then return to step 2.

How to Open an Existing Project

Follow these steps to open an existing project:

1. From the Project menu, select Set Current ->.

2. Select the project file to open. For the dhry demo program select the file dhry_1.pjt in the subdirectory dhry in the examples subdirectory of the TriCore product tree. If you have used the defaults, the file dhry_1.pjt is in the directory c:\ctri\examples\dhry.

How to Load/Open Files

The next two steps are not needed for the demo program because the files dhry_1.c and dhry_2.c are already open. To load the file you want to look at:

1. From the Project menu, select Load Files...

The Choose Project Files to Edit dialog appears.

2. Choose the file(s) you want to open by clicking on it. You can select multiple files by pressing the <Ctrl> or <Shift> key while you click on a file. With the <Ctrl> key you can make single selections and with the <Shift> key you can select everything from the first selected file to the file you click on. Then click OK.

This launches the file(s) so you can edit it (them).

Check the directory paths

1. From the Project menu, select Directories....

The Directories dialog appears.

2. Check the directory paths for programs, include files and libraries. You can add your own directories here, separated by semicolons.

3. Click OK.

How to Build the Demo Application

The next step is to compile the file(s) together with its dependent files so you can debug the application.

Steps 1 and 2 are optional. Follow these steps if you want to specify additional build options such as to stop the build process on errors and to keep temporary files that are generated during a build.

1. From the Build menu, select Options...

The Build Options dialog appears.

2. Make your changes and press the OK button.

3. From the Build menu, select Scan All Dependencies.

4. Click on the Execute 'Make' command button. The following button is the execute Make button which is located in the ribbon bar.

If there are any unsaved files, EDE will ask you in a separate dialog if you want to save them before starting the build.

How to View the Results of a Build

Once the files have been processed you can inspect the generated messages.

You can see which commands (and corresponding output captured) which have been executed by the build process in the Build tab:

TASKING program builder vx.y rz   Build nnn SN 00000000
Compiling "dhry_2.c"
Assembling "dhry_2.src"
Compiling "dhry_1.c"
Assembling "dhry_1.src"
Linking and locating to dhry_1.out
Converting dhry_1.out to dhry_1.abs in IEEE-695 format
   .
   .
   .

How to Start the CrossView Pro Debugger

Once the files have been compiled, assembled, linked, located and formatted they can be executed by CrossView Pro.

To execute CrossView Pro:

1. Click on the Debug application button. The following button is the Debug application button which is located in the toolbar.

CrossView Pro is launched. CrossView Pro will automatically download the compiled file for debugging.

How to Load an Application

You must tell CrossView Pro which program you want to debug:

1. From the File menu, select Load Symbolic Debug Info...

The Load Symbolic Debug Info dialog box appears.

2. Click Load.

How to View and Execute an Application

To view your source while debugging, the Source Window must be open. To open this window:

1. From the View menu, select Source->Source lines.

The source window opens.

Before starting execution you have to reset the target system to its initial state. The program counter, stack pointer and any other registers must be set to their initial value. The easiest way to do this is:

2. From the Run menu, select Reset Target System.

To run your application step-by-step:

3. From the Run menu, select Animate.

The program dhry_1.abs is now stepping through the high level language statements. Using the Accelerator bar or the menu bar you can set breakpoints, monitor data, display registers, simulate I/O and much more. See the CrossView Pro Debugger User's Guide for more information.

How to Start a New Project

When you first use EDE you need to setup a project space and add a new project:

1. From the File menu, select New Project Space...

The Create a New Project Space dialog appears.

2. Give your project space a name and then click OK.

The Project Properties dialog box appears.

3. Click on the Add new project to project space button.

The Add New Project to Project Space dialog appears.

4. Give your project a name and then click OK.

The Project Properties dialog box then appears for you to identify the files to be added.

5. Add all the files you want to be part of your project. Then press the OK button. To add files, use one of the 3 methods described below.

The new project is now open.

6. From the Project menu, select Load Files... to open the files you want on your EDE desktop.

EDE automatically creates a makefile for the project. EDE updates the makefile every time you modify your project.

2.6.2 Using the Control Program

A detailed description of the process using the sample program dhry is described below. This procedure is outlined as a guide for you to build your own executables for debugging.

1. Make the subdirectory dhry of the examples directory the current working directory.

2. Be sure that the directory of the binaries is present in the PATH environment variable.

3. Compile, assemble, link and locate the modules using one call to the control program cctri:

The -g option specifies to generate symbolic debugging information. This option must always be specified when debugging with CrossView Pro.

The -M option specifies to generate map files.

The -o option specifies the name of the output file.

The command in step 3 generates the object files dhry_1.obj and dhry_2.obj, the linker map files dhry_1.lnl and dhry_2.lnl, the locator map files dhry_1.map and dhry_2.map and the absolute output file dhry_1.abs. The file dhry_1.abs is in the IEEE Std. 695 format, and can directly be used by CrossView. No separate formatter is needed.

Now you have created all the files necessary for debugging with CrossView Pro with one call to the control program.

If you want to see how the control program calls the compiler, assembler, linker and locator, you can use the -v0 option or -v option. The -v0 option only displays the invocations without executing them. The -v option also executes them.

The control program shows the following command invocations without executing them (UNIX output):

dhry_1.c:
+ ctri -e -g -o /tmp/cc2154b.src dhry_1.c
+ astri /tmp/cc2154b.src -e -ghl -o dhry_1.obj
dhry_2.c:
+ ctri -e -g -o /tmp/cc2154c.src dhry_2.c
+ astri /tmp/cc2154c.src -e -ghl -o dhry_2.obj
+ lktri -e -M dhry_1.obj dhry_2.obj -lc -lfpn -Ltc1 -o/tmp/cc2154d.out
+ lctri -e -M -dtri.dsc /tmp/cc2154d.out -odhry_1.abs

The -e option removes output files after errors occur. The -gsl option of the assembler specifies to pass HLL debug information and to generate local symbols debug information. The -O option of the linker specifies the basename of the map file. The -lc options of the linker specifies to link the appropriate C library. The -d option of the locator specifies the name of the locator description file.

As you can see, the tools use temporary files for intermediate results. If you want to keep the intermediate files you can use the -tmp option. The following command makes this clear.

This command produces the following output:

dhry_1.c:
+ ctri -e -g -o dhry_1.src dhry_1.c
+ astri dhry_1.src -e -ghl -o dhry_1.obj
dhry_2.c:
+ ctri -e -g -o dhry_2.src dhry_2.c
+ astri dhry_2.src -e -ghl -o dhry_2.obj
+ lktri -e -M dhry_1.obj dhry_2.obj -lc -lfpn -Ltc1 -odhry_1.out
+ lctri -e -M -dtri.dsc dhry_1.out -odhry_1.abs 

As you can see, if you use the -tmp option, the assembly source files and linker output file will be created in your current directory also.

Of course, you will get the same result if you invoke the tools separately using the same calling scheme as the control program.

As you can see, the control program automatically calls each tool with the correct options and controls. The control program is described in detail in Chapter Compiler Use.

2.6.3 Using the Makefile

The subdirectories in the examples directory each contain a makefile which can be processed by mktri. Also each subdirectory contains a readme.txt file with a description of how to build the example.

To build the dhry demo example follow the steps below. This procedure is outlined as a guide for you to build your own executables for debugging.

1. Make the subdirectory dhry of the examples directory the current working directory.

This directory contains a makefile for building the dhry demo example. It uses the default mktri rules.

2. Be sure that the directory of the binaries is present in the PATH environment variable.

3. Compile, assemble, link and locate the modules using one call to the program builder mktri:

This command will build the example using the file makefile.

To see which commands are invoked by mktri without actually executing them, type:

This command produces the following output:

TASKING TriCore program builder   vx.yrz Build nnn
Copyright 1996-year Altium BV     Serial# 00000000
cctri -c -o dhry_1.obj -g -w91 -w303 dhry_1.c
cctri -c -o dhry_2.obj -g -w91 -w303 dhry_2.c
cctri -o dhry_1.abs dhry_1.obj dhry_2.obj

The -g option in the makefile is used to instruct the C compiler to generate symbolic debug information. This information makes debugging an application written in C much easier to debug.

The -w option in the makefile is used to suppress a warning.

The -o option specifies the name of the output file.

To remove all generated files type:


Copyright © 2002 Altium BV