Part Number: OMAP-L138
Other Parts Discussed in Thread: C6000-CGT,
Tool/software:
Hello,
We, at SBG systems, have been using the C6000-CGT tools for a number of years now for code targeting the DSP (C674x) of the OMAP-L138 SoC. However, as of recently, we need to port a C++ code base to run on the DSP. We've tried doing this with the C6000-CGT tools, but compiling was extremely long, and often failed with internal compiler errors. This became a blocking problem for us.
After a number of attempts, we've decided to switch to GCC, and we've successfully built a toolchain with which we could build and run our current C code base, and also our new C++ code base in an experimental branch. We did this with GCC 13.3.1 (git maintenance branch) but we could probably have used the latest GCC version instead, since the c6x target is still supported.
We've had two issues with GCC, both related to exception handling:
Thread-safety: Thread-local storage isn't implemented in GCC for c6x. We've used the TLS emulation layer of GCC, in a way similar to VxWorks, to achieve exception handling thread safety.
RTTI: There seems to be a small issue in binutils with regard to EHTYPE relocation types, i.e. they are DP-relative GOT-indirect instead of being only DP-relative. We could tweak our linker scripts so that the data pointer would have the "right address" to allow pointer encoding to work, but it seemed too diry, so we've patched binutils and gcc to encode type_info addresses as DP-relative only instead. By the way, I'd appreciate if anyone here can confirm if a GOT indirection on top breaks the ABI or not, my understanding being that it does, but then I wonder why it was implemented that way. Thanks.
In addition, we've noticed that the assembler doesn't generate 16-bits compact instructions, and that the generated code was about 1.5x slower than with the C6000-CGT tools, with comparable optimizations (LTO and whole program optimizations at -O3). However, our new C++ code base benefits a lot from higher level optimizations, in particular from templates, making a lot of computations done directly at compile time, so we're still pretty happy with the move, but we suspect that the resulting machine code could benefit from better instruction scheduling and caching.
All in all, those were minor issues, and the people who wrote the initial implementation as well as those who did the maintenance over more than 10 years have done a pretty good job (thanks to them). My question is: would TI consider (re)starting GCC support for the c6x and/or c7x architecture ? We've come to rely quite heavily on exceptions, template libraries, and some C++ >14 features, so those are now strong requirements for us going forward. I suspect we may not be alone in that situation, or interested in a reliable implementation of those features.
Thanks.
For people who may be interested in our work, see https://github.com/SBG-Systems/sbgToolchain.
