C4x GCC

GCC Installation

The following steps can be used to build gcc for the c4x or alternatively you can use the script c4x-gcc-build . Note that you need to have previously installed the binutils for the c4x.

Acquire and unpack gcc source tree. You can either download the gcc-3.0.0 tarball or use CVS (see the script c4x-gcc-update for an example of how to do this.)
Patch gcc source tree with c4x patches. This step is optional since the gcc source tree contains c4x support. However, the latest stable optimisation patch is gcc-3_0-c4x-20010619.patch.gz.
Create a build directory, say mkdir obj-gcc-c4x .
Configure gcc:
```
cd obj-gcc-c4x
../gcc/configure --target=c4x --prefix=/usr  -enable-language={c,c++}
	
```
(Note that if you want gcc installed in /usr/local/lib/lib-gcc, then use --prefix=/usr/local which is the default.)
Build gcc:
```
make
	
```
(Note that just typing make will fail when trying to build the libraries unless you the c4x binutils installed. It will also fail when checking for the executable suffix unless you have a C run-time start up file crt0.o somewhere accessible. This can be a dummy object file as long as it defines the sybmol _start.)
Install gcc (usually as root):
```
make install
	
```

GCC Development

The C4x GCC backend has been incorporated into GCC since GCC 2.95. However, there are some important optimisations we require for the C4x that have not been submitted or accepted yet:

Improved autoincrement addressing modes generation.
Post/pre-modify addressing modes.
Parallel instruction packing.

The improved autoincrement addressing modes generation generates much better code for the C4x. However, before I submit it I want to rewrite it using the dataflow routines I wrote for the new register allocator.

The parallel instruction packing pass works well but could be made more efficient. I submitted it for inclusion into gcc (but it appears to slipped into a black hole...).

To use these optimisations you will need to apply the patches that I generate from my source tree against the latest GCC development tree. I generate these patches spasmodically against the latest GCC development snapshot and store them in http://www.elec.canterbury.ac.nz:/c4x/devel ).

You can grab gcc snapshots using FTP (they are generated daily) or better still, you can use anonymous CVS access to the main GCC repository.

The more sets of eyes that scrutinise the generated code the better. As I nail down one problem area, some other problem might pop up elsewhere, so don't assume that I know what I'm doing. If you are wondering why a particular bug is not being fixed it is probably due to the fact that we do not know about it. I cannot scan all the generated code and sometimes there are trivial fixes for suboptimal code. If you see a piece of hopeless code, send me a snippet of the C source and what you reckon GCC should output. There is a lot of scope for pulling little tricks, say for logical operations using constants that won't fit into 16-bits.

To see the assembly code that GCC generates for a given C file, invoke GCC as follows, c4x-gcc -O2 -S file.c (or c4x-gcc -m30 -O2 -S file.c) and have a look at file.s

If you're more adventurous, add the option -da. This will cause GCC to emit many files using the RTL (Register Transfer Language) to describe what it has done after every pass. Have a look at the passes section in the GCC info to see what gets done when... I also find the -dp option is useful to annotate the generated assembly file with the names of each of the insns.

Last modified: Sat Jun 23 14:55:38 NZST 2001