GCC released for C6000 DSP

[jkridner]

I think this code will largely be upstream before all of the programming infrastructure in OE is moved from the TI compiler to GCC, but if you are wanting to build some DSP code today...


The linux-c6x.org project has produced a downloadable C6000 GCC compiler: https://sourcery.mentor.com/GNUToolchain/release1882


This means not being locked into a TI toolchain and also having the potential for freely redistributing the toolchain, even if it is compiled to run on the ARM such that you can run the compiler on your Pandora.


To talk to the DSP, the 'virtio' code for OMAP3 has made its way pretty well upstream and should be in any recent kernels. There was a talk on 'virtio' last week at ELC (http://elinux.org/ELC_2012_Presentations) and their is some documentation up on OMAPedia (http://omappedia.org/wiki/Category:RPMsg).

 

[EvilDragon]

Just in time with our new release that also supports the DSP optionally


How useful will this be for existing programs?


Can this toolchain be implemented into an existing one to use the DSP for e.g. audio playing in your program so you use less CPU?


As I'm no dev - is this easy to use? i.e. can you just code some SDL app and run it on the DSP with this compiler?

 

[notaz]

To talk to the DSP, the 'virtio' code for OMAP3 has made its way pretty well upstream and should be in any recent kernels. There was a talk on 'virtio' last week at ELC (http://elinux.org/EL...2_Presentations) and their is some documentation up on OMAPedia (http://omappedia.org.../Category:RPMsg).

Thats all good and well, but are you sure it covers OMAP3? From what I've read it's OMAP4+ only and only supports ELF binaries, so only useful for extra OMAP4+ ARM cores, not the DSP.

 

[ibisum]

The Assembler supports:

Sourcery CodeBench Lite for C6000 uClinux includes the following library configuration.


C64x+ - Little-Endian


Command-line option(s): default


Sysroot subdirectory: ./


C64x+ - Big-Endian


Command-line option(s): -mbig-endian


Sysroot subdirectory: be/


C674x - Little-Endian


Command-line option(s): -march=c674x


Sysroot subdirectory: c674x/


C674x - Big-Endian


Command-line option(s): -mbig-endian -march=c674x


Sysroot subdirectory: be/c674x/

We are C64x+, so .. win!

 

[Stradian]

Will this allow what the ME did for the PSP? Which means that we could do what dealdusX64 did and separate the audio thread from the main cpu.

 

[ibisum]

With this we should be able to put all sorts of great code on the DSP to make things smoother for the main CPU to do other tasks ..

 

[Stephane Hockenhull]

Just in time with our new release that also supports the DSP optionally


How useful will this be for existing programs?


Can this toolchain be implemented into an existing one to use the DSP for e.g. audio playing in your program so you use less CPU?


As I'm no dev - is this easy to use? i.e. can you just code some SDL app and run it on the DSP with this compiler?

from what I understood, and if it is like other DSP co-processor I've seen, you send data and a piece of code to the DSP, it process the data and when its done you read back the result.


it can't run whole applications, only "simple" functions (relatively speaking) and you need to add code to do the data transfers and handshakes (it does not access the application's virtual memory directly)


its similar to a GPU's compute shader, OpenCL, etc.


for example, in an video player, the ARM cpu is still responsible for reading the data, sending it to the DSP, then copying/DMA the decompressed pixels to the video frame buffer.


there is a cost of transferring data back and forth.


one thing the DSP might be excellent at is doing the custom rendering for emulators of old hardware provided the emulator can do deferred rendering.


but this would need a lot of work, its not a port but a significant rewrite of rendering code.


still, this is excellent news.

 

[Exophase]

The C6x DSP on OMAP3530 is fully autonomous and has direct access to memory. It's not a coprocessor. TI sells many microcontrollers where all program code is executed by one or more C6x DSPs. Its MMU is simpler than the Cortex-A8's and of course the two are not cache coherent with each other, but some manner of simple virtual memory based sharing is possible.


This news doesn't seem very significant to me because I don't really know what was wrong with TI's compiler. C6x is very hard to schedule/optimize for and I'd be shocked if GCC is generating code that's even a small fraction as fast as what TI's compiler generates.

 

[Stephane Hockenhull]

The C6x DSP on OMAP3530 is fully autonomous and has direct access to memory. It's not a coprocessor.

maybe, but in the case of Linux it acts as a coprocessor.


unless there's a full user space support and C6x code can make any system calls (file I/O, etc) on the Pandora/Linux it is a coprocessor.


GCC supporting C6x is good news because it will enable things like OpenCL and other situations where you want to generate DSP code on the fly.

 

[jkridner]

The C6x DSP on OMAP3530 is fully autonomous and has direct access to memory. It's not a coprocessor.

maybe, but in the case of Linux it acts as a coprocessor.


unless there's a full user space support and C6x code can make any system calls (file I/O, etc) on the Pandora/Linux it is a coprocessor.


GCC supporting C6x is good news because it will enable things like OpenCL and other situations where you want to generate DSP code on the fly.

The C6run utility provides a C6000 C library and ARM launcher that provides the C6000 with basic system calls such as file I/O. With this mechanism, you can launch C6000 applications that run as independent programs.

 

[jkridner]

This news doesn't seem very significant to me because I don't really know what was wrong with TI's compiler. C6x is very hard to schedule/optimize for and I'd be shocked if GCC is generating code that's even a small fraction as fast as what TI's compiler generates.

The challenge I've had with the TI compiler, which is perfectly fine, is that it doesn't allow for free redistribution, porting and integration. The interprocessor communication tools need some integration to work with a specific kernel and libraries that would be best part of your full Linux distribution and perhaps even made available to run on the ARM. If you were invested before in producing C6000 code, this new compiler doesn't give you all that much new capability, but if you are trying to lower the barriers to entry, being able to freely redistribute and integrated SDK as part of your distribution can make developing C6000 code just about as easy as developing code for the ARM.