1 TCE Compiler

TCE compiler compiles high level language (such as C/C++) source files provided by the toolset user and produces a bitcode program or a parallel TTA program. Bitcode program is a non-architecture specific sequential program. Parallel TTA program, however, is a architecture specific program that is optimized for the target architecture.

The main idea between these two program formats is that you can compile your source code into bitcode and then compile the bitcode into architecture dependent parallel code. This way you do not have to compile the source code again every time you make changes in the architecture. Instead you only need to compile the bitcode into parallel code.

The frontend compiler uses the LLVM C compiler which again is built on GCC version 4.

Input: program source file(s) in high-level language

Output: a fully linked TTA program

1 Usage of TCE compiler

The usage of the tcecc application is as follows:

tcecc <options> source-or-bc-file1 source-or-bc-file2 ...

The possible options of the application are the following:

1 Examples of usage

Usage of tcecc quite alike to gcc, excluding that warning options are ignored.

If you wish to compile your source code into optimized bitcode the usage is:

tcecc -O2 -o myProg myProg.c

On the other hand if you already have an architecture definition file of the target processor you can compile the source code directly to parallel program:

tcecc -O2 -a myProcessor.adf -o myProg.tpef myProg.c

To compile the bitcode program into parallel program use:

tcecc -a myProcessor.adf -o myProg.tpef myProg.bc

Or if you want to a different scheduling configuration than the default:

tcecc -s /path/to/mySchedulerConfiguration.conf -a myProcessor.adf -o myProg.tpef myProg.bc

Tcecc also has a ``leave dirty'' flag -d which preserves the intermediate files created by the compiler. After compilation is complete tcecc will tell you where to find these files (usually it is /tmp/tcecc-xxxxxx/). For example if you try to compile your C-code straight into a scheduled program and something goes wrong in scheduling you can find the bitcode program from the temp directory.

tcecc -d -O2 -a myProcessor.adf -o myProg.tpef myProg.c

After compilation you should see this kind of message:

Intermediate files left in build dir /tmp/tcecc-xxxxxx

where xxxxxx is a random pattern of characters.

If you only want to compile the source code without linking (and optimization) use -c flag. Output file is named after the source file with .o appendix if you do not define an output name with -o.

tcecc -c myProg.c

tcecc -c -o /another/path/myProg.o myProg.c

With tcecc you can explicitly define symbols you wish to preserve in the binary. This can be useful in debugging and profiling if the compiler removes needed function labels. Symbols are given in a comma seperated list.

tcecc -O2 -a myMach.adf -k main,foo,bar -o myProg.tpef myProg.c

1 Plugins

2 Custom operations

Tcecc compiler automatically defines macros for operations found from operation definition files in OSAL search paths and includes them when compiling your program.

The macros use the following format:

_TCE_<opName>(input1, ... , inputN, output1, ... , outputN);

where <name> is the operation name defined in OSAL. Number of input and output operands depends on the operation.

There are also versions of the custom operation macros which can be used to explicitly target an function unit (FU).

Usage of the ``explicit-FU`` macros is as follows:

 _TCEFU_<opName>(<fuName>, input1, ... , inputN, output1, ... , outputN);

where <fuName> is the name of the target function unit in ProDe.

There are also versions of the custom operation macros which can be used to target specific address space for operations that use memory. These may be need to be used for custom memory operations on architectures with multiple memory address spaces, as the address space information of a pointer may be lost with the ordinary custom operation call.

 _TCEAS_<opName>("#<as-numerical-id>", input1, ... , inputN, output1, ... , outputN);

or

 _TCEAS_<opName>("<as-name>", input1, ... , inputN, output1, ... , outputN);

where <as-numerical-id> is the numerical id of the target address space, and <as-name> is the name of the target address space. This name is NOT necessaryly the same as the keyword in C code, this is the name visible in ProDE. Numerical id 0 is always where where the stack is located.

Examples of usage:

 
 _TCE_MAC(a, b, c);
 _TCEFU_MAC("MAC1", a, b, c);
 _TCEAS_LDW("#1", a, b)
 _TCEAS_LDW("my_huge_global_addresspace", a, b)

3 Endianess Mode

Endianess mode property of the target architecture determines how the initialized data is layout into the data memories and operation selections for accessing the memories by the compiler. In the table 5.2 is list of memory operations required by the compiler in the selected endianess mode.

Table 5.2: The required memory operations in the selected endianess modes.

Big endian	Little endian
ldq	ld8
ldqu	ldu8
ldh	ld16
ldhu	ldu16
ldw	ld32
stq	st8
sth	st16
stw	st32

The endianess mode is selected in ProDe's Architecture Features... dialog (Edit -> Architecture Features...).

4 Known issues

1. Currently it is not possible to simulate a bitcode format program. But the advantage of bitcode simulation is quite non-existent because the bitcode does not even contain the final basic blocks that the architecture dependent program has.