Experimental C64X backend

Hi,

Over the past few months I've been developing a LLVM backend for TIs
C64X family of DSPs. It can be found as a co-processor in a variety of
OMAP-based devices such as gumstix, beagleboard and even Nokia's N900
phone. A project I'm working on [0] has had need to put code on it, and
we wanted to avoid TIs proprietary compiler.

The DSP itself is a VLIW machine, with 64 32-bit registers in two banks
and can execute up to eight instructions a cycle. There are some
SIMD-like instructions, and well-known DSP features like circular
addressing and some onboard memories. A full description is on TIs
website at [1].

The work I've done is implementing simple codegen for the machine (as
well as a binutils port). I haven't gone anywhere near the parallel
functionality. As is well known, LLVM doesn't have any support or
frameworks for taking advantage of the advanced portions of VLIW.

Part of the motivation for this project was giving opportunity /
encouragement for developing such frameworks.

The code itself can be found in the git repo at [2] and is based on LLVM
2.7. (Binutils is at [3]). I'd welcome any feedback regarding the LLVM
backend - I've no prior experience with LLVM, so it's far from optimal
right now. In case anyone has a device handy, I've put some brief
documentation on getting code running at [4].

[0] http://studentrobotics.org
[1] http://focus.ti.com/lit/ug/spru395b/spru395b.pdf
[2] git://git.srobo.org/llvm-tic6x.git
[3] git://git.srobo.org/tic6x-binutils.git
[4] http://www.studentrobotics.org/trac/wiki/Beagleboard_DSP

Hi,

Over the past few months I've been developing a LLVM backend for TIs
C64X family of DSPs. It can be found as a co-processor in a variety of
OMAP-based devices

Interesting!

The code itself can be found in the git repo at [2] and is based on LLVM
2.7. (Binutils is at [3]).

Are you intending to keep the development separate or merge to both
projects' upstream?

I'd welcome any feedback regarding the LLVM
backend - I've no prior experience with LLVM, so it's far from optimal
right now.

Hey, at least it compiles non-trivial programs! Out all the DSP test
cases I have for the SPU, only a handful don't compile with your
backend :slight_smile: Now if I only could get them running on the C64x... (I cannot
seem to "allocate dsp node", but that is just my lacking OMAP skills)

kalle

Hi,

The code itself can be found in the git repo at [2] and is based on LLVM
2.7. (Binutils is at [3]).

Are you intending to keep the development separate or merge to both
projects' upstream?

Ultimately I'd like that to happen; of course more work is required to
get the code in a fully stable state.

For binutils however, TI are funding development for C6X support [0],
which in addition to C64X supports C62X and C67X DSPs. That project
has already been blessed by the binutils folks, has a wider scope than
what I've implemented, and it's unlikely that they'll take a code
donation of duplicate functionality.

I'd welcome any feedback regarding the LLVM
backend - I've no prior experience with LLVM, so it's far from optimal
right now.

Hey, at least it compiles non-trivial programs! Out all the DSP test
cases I have for the SPU, only a handful don't compile with your
backend :slight_smile:

Excellent - I haven't performed any comprehensive testing yet, but
that sounds promising.

Now if I only could get them running on the C64x... (I cannot
seem to "allocate dsp node", but that is just my lacking OMAP skills)

Unfortunately TI don't make it easy to compile + load code manually
(they only _support_ it when using their "CodeComposer" tools). That
particular error is normally due to a mismatch between the GUID
embedded in the DSP binary and the GUID/node being allocated. Feel
free to mail me off-list to work this one out - it'd be great to get
something other than my own few tests running.

[NB - I'm currently wandering around Canada, so internet access is intermittent]

[0] http://linux-c6x.org/about/