This is the major repository of the patches required to the GNU compiler tools to support the TMS320C3x and TMS320C4x digital signal processor chips from Texas Instruments. The TMS320C4x DSPs are souped up versions of the TMS320C3x; here both these DSP families are referred to by the C4x abbreviation.
The software is still undergoing improvements and I welcome any help that I can get. The compiler is producing efficient and reliable code, but you use it at your own risk, i.e., the standard disclaimers apply and there is absolutely no WARRANTY as described under the terms of the GNU GPL (General Public Licence). Having said that, I use the compiler regularly for my work (C30 small model) and successfully use it with some large applications, including my operating system and libraries.
Suggestions, bug reports, feedback, patches to gcc_c40@atlantek.com.au (to subscribe to this mailing list send a message with subscribe gcc_c40 in the body to majordomo@atlantek.com.au).
The C4x target of GCC ( c4x-gcc ) has been included in the gcc distribution GCC since version 2.95 but without some of the more useful optimisations (improved autoincrement addressing mode generation and parallel instruction packing). The latest stable version of GCC is GCC 3.0; my development patches patch against the GCC 3.1 development sources.
The C and C++ front-ends of GCC are known to work with the C4x target. The FORTRAN front-end will not currently work as a cross-compiler due to some assumptions about type sizes.
The C4x port of GCC ( c4x-gcc ) will produce code for the C3x DSPs as well (use -m30 option).
The binutils includes programs such as the GNU assembler (gas), linker (ld), and archiver (ar), plus other goodies for dumping (disassembling) object files (objdump), copying object files to a different format (objcopy), listing symbol names within object files (nm), and stripping debug symbols from object files (strip).
The c4x-binutils uses COFF (the Common Object File Format), well the same uncommon, kludged variant as used by the TI assembly language tools for the C[34]x. This allows cross linking of object files and compatability between the tool sets. The new version of TI's COFF (V2) is generated by default.
To use the C4x binutils you will have to apply the C4x binutils patches to the binutils source tree. Now that binutils supports the C54x a lot of hackery we required has gone. I hope to submit the C4x binutils patches at some stage but am currently too busy with real work commitments.
GDB is a symbolic high-level language debugger. The C4x version is c4x-gdb . It also contains a wonderful simulator for the C4x (written by Herman ten Brugge) that provides cycle accurate profiling, a display of pipeline conflicts, support for multiple threads, connection of I/O ports to files or sockets, among other things. The first time I used this on one of my programs I found that I had forgotten to enable the instruction cache! My program soon ran a lot faster...
To use the simulator you will have to apply the C4x GDB patches to the GDB source tree. I do not envisage pushing for inclusion of these patches into the GDB source tree (without some financial inducement!) due to the large number of changes required. The problem is that GDB assumes that the host and target system use the same sized bytes.
I have written this package to provide a generic loader and GDB server for the C4x, c4x-utils . It has been written to be independent of the target system using a generic DSP target interface. It should also be able to support other DSPs other than the C4x with little modification.
Currently there are no freely available C and math libraries available for the C4x. I use a severely hacked version of the TI C run-time library which works with my operating system, MPHOS. The GNU C library appears to be too complex to be ported to embedded systems at the moment. A better choice would be newlib , a GPL'd C library for embedded systems from RedHat. Ran Cabell has done some work to retarget newlib for the C4x but I have not used it and am unsure of the state of play.
Volker Kuhlmann has provided crt-1.1.tar.gz which implements simple start-up routines for each of the memory models to interface to the TI C run-time system. He has also provided ti-rts-1.32.tar.gz to patch the TI run time system files to work with c4x-gcc.
You have to build the C4x tools from the source distributions with my patches. I do not supply binaries since I do not have the time and I want to encourage you to look at the sources and to improve them. For a fee, I will generate binaries if you are desperate!
Build and install binutils (see Binutils Installation ).
Build and install gcc (see GCC Installation ).
Build and install run-time libraries.
Build and install gdb (optional).
c4x-gcc -m30 -O2 -msmall -mmpyi -mdb -mloop-unsigned -mfast-fix
By default, the compiler produces safe but unexciting code. If you want better optimised code you have to specify the specific optimisation switches, but there are caveats associated with each of these switches in very rare cases, for example if you have an iteration count greater than 2^31. The caveats are mentioned in greater detail in the GCC manual.
If the building of GCC dies when trying to use itself to compile libgcc1.S, the most likely problem is that GCC cannot find the correct assembler (you will either get an error message saying unknown opcode or unknown switch depending on which assembler was invoked). Usually this is because the binutils for the C4x have not been installed or have not been correctly installed. If the prefixes aren't quite right, a well placed symbolic link can breathe life into the monster (say from /usr/c4x to /usr/local/c4x on a Linux system if you didn't specify the prefix as /usr/local).
Use
If the assembler c4x-as barfs when assembling GCC generated code upgrade the c4x-binutils. GCC now outputs registers with floating point values as Fn instead of Rn. This helps me to see how registers are being allocated and to force everyone to upgrade ;-)
Some relief may be found in the form of cygwin for those poor folks whose employers insist that they use half-arsed operating systems from a certain software company.
If you think you've found a bug, check out the known list of bugs . If it is not listed, send me the smallest example function that exhibits the problem after running your code through the preprocessor, by using the -save-temps option to gcc. This will generate a file with a .i extension.
The best documentation for GCC and other tools are the info files. I read these using GNU Emacs although they can be converted to HTML. Printable versions of the documents can also be prepared, but be warned that GCC required more than 500 sheets of paper the last (and only) time I printed it. Online docs are also available.
If you are just starting out, Volker Kuhlmann has written a blow by blow account of the installation process for a RedHat GNU/Linux system (see README-C30 ). Matt Donadio has also put together some frequently asked questions with answers (see the FAQ ). Note that both these documents are more than a little dated so take them with a grain of salt or better still, update them for me.
I don't have a lot of spare time at the moment to write docs, and it is probably best if someone else away from the coal face has a crack at this. Besides, the more people who have to dive in looking at the source code, the better the code will become, and the more time I'll have to spend tinkering on other things... Having said that, I have started writing a User's Guide explaining how to use the GNU tools for the C4x. This document can also be downloaded in the following formats: texinfo , postscript , and info .
Unfortunately, there are only a few folks actively working on these tools in their spare time; namely me, Michael Hayes, and Herman ten Brugge. My spare time has been severely chewed into recently and I would be grateful for any assistance. There are still lots of things to do , from adding new optimisations to writing documentation.
Suggestions, bug reports, feedback, patches to c4x@elec.canterbury.ac.nz and/or to gcc_c40@atlantek.com.au (to subscribe send a message with subscribe gcc_c40 in the body to majordomo@atlantek.com.au). I make new announcements to the latter mailing list.
If you want a blow by blow description of the trials and tribulations of the compiler development, email me and I'll add you to the developer mailing list.
If you don't like the assembly code generated, try tweaking the optimisation switches. If you are still unhappy, send me a test case for a simple function and the code that you would like to see generated. It's easy for me to overlook trivial optimisations and I cannot fix them if I'm unaware of them! I tend to work on optimisations that will improve the code that I have written ;-) Better still, jump in the deep end and look at the machine description for the C4x backend to GCC. I'm sure that there are lots of other cunning tricks that I have missed.
Grizzles to /dev/null
Copyright ©1997,1998,1999,2000,2001 Michael Hayes (m.hayes@elec.canterbury.ac.nz)
Last modified: Sat Jun 23 14:52:18 NZST 2001