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 -- Thanks, Jeremy -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100812/698bcd7b/attachment.sig>
On Thu, 2010-08-12 at 12:03 +0200, Jeremy Morse wrote:> 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 devicesInteresting!> 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 :) 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,> On Thu, 2010-08-12 at 12:03 +0200, Jeremy Morse wrote: >> 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 :)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/ -- Thanks, Jeremy