GCC released for C6000 DSP

Discussion in 'NEON / DSP' started by jkridner, Feb 22, 2012.

  1. jkridner

    jkridner Still Fresh

    Joined:
    Oct 12, 2008
    Messages:
    4
    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).
     
    Tags:
  2. EvilDragon

    EvilDragon Administrator Staff Member

    Joined:
    Mar 4, 2003
    Messages:
    19,651
    Location:
    Ingolstadt
    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?
     
  3. notaz

    notaz Certified Guru

    Joined:
    Aug 23, 2005
    Messages:
    4,911
    Location:
    Lithuania
    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.
     
  4. ibisum

    ibisum Well-Known Member

    Joined:
    May 6, 2009
    Messages:
    1,135
    The Assembler supports:

    We are C64x+, so .. win!
     
  5. Stradian

    Stradian Member

    Joined:
    Dec 6, 2010
    Messages:
    304
    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.
     
  6. ibisum

    ibisum Well-Known Member

    Joined:
    May 6, 2009
    Messages:
    1,135
    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 ..
     
  7. Stephane Hockenhull

    Stephane Hockenhull Member

    Joined:
    Sep 12, 2010
    Messages:
    282
    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.
     
  8. Exophase

    Exophase Nothing good will ever come of Exophase.

    Joined:
    Sep 21, 2006
    Messages:
    10,308
    Location:
    Cleveland OH
    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.
     
  9. Stephane Hockenhull

    Stephane Hockenhull Member

    Joined:
    Sep 12, 2010
    Messages:
    282
    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.
     
  10. jkridner

    jkridner Still Fresh

    Joined:
    Oct 12, 2008
    Messages:
    4
    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.
     
  11. jkridner

    jkridner Still Fresh

    Joined:
    Oct 12, 2008
    Messages:
    4
    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.
     

Share This Page

Loading...