This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

ELF versions of 64x libraries

Hi,

I'm currently working to migrate a CCSv3.3 COFF-based project to a CCSv4 ELF-based project. The project links against the following TI libraries:

dsp64x.lib, fastrts64x.lib, c64x_fixedpt_fxns.lib

Do you currently provide ELF versions of these libraries?

If not, is there any workaround (other than the obvious choice of just not using these libraries) or will i have to wait until you have these available?

Thanks,
Mike

  • No, sorry, we don't have ELF version of those libraries.  I don't even recognize the c64x_fixedpt_fxns.lib.  Where did you find that one?  If you're using 64x libraries then I assume you're on a pretty old processor like the 6416.  What's your motivation for moving to ELF?  I think your only option is to rebuild the libraries as ELF.

  • c64x_fixedpt_fxns.lib was provided to us by TI back in 2003. I'm trying to find the original e-mail to reference. It included functions like sqrt32, sqrt32_vec, arctan32, etc...

    We're not required to use 64x libraries, we can use 64x+ libraries, we just haven't updated to these as of yet. Are there 64x+ version of the fastrts or dsplib libraries in ELF format?

    The motivation for moving to ELF is that we provide libraries to vendors that are using the new Shannon DSPs and their projects are ELF-based, so we need to provide them ELF libraries in order for them to work with them. The problem is that a number of the performance optimizations to our library rely on the functions in the libraries i mentioned, so if you don't have ELF versions of those libraries, we'll have to revert to slower code.

    I know there's source available for the DSPLIB, but is there source for the fastrts or c64x_fixedpt_fxns libraries? I'll need source to rebuild the libraries as ELF.

    Thanks,

    Mike

  • The fast rts library contains a bunch of emulated floating point instructions.  You absolutely do not want to deliver an ELF version of that library to your customer.  The 66x has native floating point support so you want to utilize that capability rather than running a bunch of fixed point instructions to emulate floating point.

    There are new versions of DSPLIB specifically for 66x architecture:

    http://focus.ti.com/docs/toolsw/folders/print/sprc265.html

    That's what I recommend using as you will not only get an ELF library but also take better advantage of the underlying hardware.

  • Which device are you using?

     

     

  • Sorry.  It turns out the latest DSPLIB still does not include ELF libraries!  However, all the source code is included such that you can rebuild the libraries for ELF.

  • Mike,

    Please find the ELF version of the C64X+ DSP libraries in the attachment here. 0042.ELF_libraries.zip

    I do not know of a C64x_fixedpt_fxn.lib that you have mentioned above so I do not have that library in the attachment. If you can find the library on TI.com we can help you in creation of the ELF version of that library.

    Regards,

    Rahul

  • Thanks for all the help!

    I'm not using a specific platform because we provide audio encoder/decoder libraries to companies to use on the platform of their choice. So, in this case, we provide general purpose 64x libraries that can be used on any device with either a 64x or 64x+ core.

    As it stands right now, i believe that all of our customers requiring ELF libraries are using the 66x devices, so your point is appreciated that these devices support native floating point and won't require the fastrts library. So i think for now, that alleviates the requirement for an ELF version of this library. If TI ever does fully move away from COFF, though, and we need to provide ELF libraries for older devices (like the 6424), then this requirement will return.

    As far as the c64x_fixedpt_fxn.lib, i need to do more research on where that library came from. I can't find any reference to it on the TI website, so i'm not sure what the story is.

    Thanks for providing the ELF version of the 64x+ DSP libraries, that will help.

    Thanks again,

    mike

  • Rahul,

    One of the libraries you provided me was "fastrts64x_elf.lib". I'm not sure if you'll be able to help with this, but for the life of me, i can't get the linker to actually use the functions in this library. It keeps using the functions from the standard RTS library. I've defined this library as first in the link order via the Link Order tab in the CCS Build section of the Build Properties dialog. This worked fine for my COFF-based project, so i'm not sure what's happening with the ELF project.

    I took a look at the C6000 EABI Migration Guide, and there's a section on RTS helper functions that mentions that the helper functions have different names under EABI. Could this be the reason the linker is not using the fastrts functions?

    Everything else has worked well that you provided. I also managed to find the source for the c64x_fixedpt_fxn library content and was able to build that as ELF. From what i could dig up, this library was provided to us in 2004 by Dipa Rao at TI and the application report that was sent along with it was written by Mattias Ahnoff and was titled "Fixed-point Implementations of Standard Math Functions on the TMS320C64x". The doc has a preliminary stamp, so it appears that this library never saw the full light of day. Anyway, that all was just for your curiosity's sake.

    Thanks,

    Mike

  • Mike,

    I inspected the fastrtsc64x library that you had reported was failing to link  appropriately. It appears that we had created that version of the library with an old version of the compiler due to which  you may be facing this issue. I have made slight modification to the source and rebuilt the library using  Compiler version 7.2.

    Attachment: 4540.fastrts64x_elf.zip

    Can you try this version and let us know if this links in correctly with your project.

    Do you have the source for the c64x_fixedpt_fxn library that you got from Dipa or was it just a binary release?

    Regards,

    Rahul

  • Hi,

    Thanks a lot for the updated library, but for some reason it's still not using the fastrts functions. The linker links just fine, but when i check the .map file i can see that it's not using the functions from the fastrts library.

    I'm using compiler version 7.2.0 and have the Runtime Support Library set to <automatic>, i'm not sure if that information helps or matters.

    I do have the source for the c64x_fixedpt_fxn library and i am able to compile this library as ELF without any problem.

    Thanks,

    Mike

     

     

  • Mike,

     We replicated the scenerio that you had reported and asked the compiler team to help us figure out the issue with the newly compiled library.  During this process we unearth a vital change in the RTS libraries that are shipped with the compiler which needed to be accounted for to make the fastrts work. The ELF migration guide shipped with the compiler documents that ELF binaries are built by removing the leading underscore from variables defined in COFF. However with in the C6000 RTS libraries a prefix "__c6xabi_" has been added to all the RTS variables while building in the ELF format. Inorder for the fastRTS variable to override the symbols from the RTS library, we had to add this prefix to all the the function names in their assembly files. I have modified the library and tested the library to ensure that this library does override the RTS functions just like the COFF version of the library. You can download the library from here :

    3554.fastrts64x_elf.zip

    Sorry for all the trouble you had to go through to get the fastrtsc64x link to your project. Do let us know if this works for you.

    Thanks and Regards,

    Rahul

  • Rahul,

    Thanks! That solution makes perfect sense, and it is now successfully linking in my project.

    Thanks for all the help, it's been great that you could resolve this so quickly for me.

    Mike