"主题"中讨论的其他器件：C6000-CGT、
工具/软件：
您好：
在 SBG 系统领域、我们多年来一直使用 C6000-CGT 工具来编写针对 OMAP-L138 SoC 的 DSP (C674x)的代码。 然而、截至最近、我们需要移植 C++代码库才能在 DSP 上运行。 我们曾尝试使用 C6000-CGT 工具执行此操作、但编译时间非常长、经常因内部编译器错误而失败。 这对我们来说是一个阻碍问题。
经过多次尝试后、我们决定切换到 GCC、并成功构建了一个工具链、通过该工具链、我们可以构建和运行当前的 C 代码库、还可以在一个实验分支中构建新的 C++代码库。 我们使用 GCC 13.3.1 (Git 维护分支)执行了此操作、但我们可能可以改用最新的 GCC 版本、因为 C6x 目标仍然受支持。
我们遇到了 GCC 方面的两个问题、这两个问题都与异常处理有关：
线程安全：在 C6x 的 GCC 中未实现线程局部存储。 我们以类似于 VxWorks 的方式使用 GCC 的 TLS 仿真层来实现异常处理线程安全性。
RTTI:在 EHTYPE 重定位类型方面,binutils 似乎有一个小问题,即它们是 DP 相对 GOT 间接的,而不是仅仅是 DP 相对的。 我们可以调整链接器脚本、以便数据指针具有"正确的地址"以使指针编码正常工作、但它似乎过于模糊、因此我们修补了 binutils 和 gcc、将 type_info 地址编码为仅 DP 相对地址。 顺便说一句、如果这里的任何人都能确认"Get Indirection" On Top 是否违反了 ABI、我的理解是它确实违反了 ABI、但我想知道为什么这样实施。 谢谢。
此外、我们注意到汇编器不会生成16位紧凑指令、并且生成的代码比 C6000-CGT 工具慢约1.5倍、采用类似的优化(LTO 和整个程序优化在-O3处)。 然而,我们的新 C++代码库从更高级别的优化中受益匪浅,特别是模板,在编译时直接完成大量计算,因此我们仍然很满意这一迁移,但我们怀疑生成的机器代码可以从更好的指令调度和缓存中受益。
总之,这些都是小问题,谁写了初始实施的人和那些做了维护10多年的人都做了相当好的工作(感谢他们)。 我的问题是：TI 是否会考虑(重新)开始为 C6x 和/或 c7x 架构提供 GCC 支持？ 我们在很大程度上 依赖于异常、模板库和一些 C++>14功能、因此 这些功能 现在对我们的未来有着很强的要求。 我怀疑在这种情况下、我们可能不是孤立无援、或者对可靠地实施这些特点感兴趣。
谢谢。
对于可能对我们的工作感兴趣的人、请访问 https://github.com/SBG-Systems/sbgToolchain。
