您好！
我的客户发送了下面的查询、MSP e2e 让我参考此论坛、因为 对底层编译器行为不是很熟悉：
根据我们 为支持我们开发新软件/硬件平台的计划而开展的技术调查、我一直在了解 TI 的 C++工具的最新状态。
总体而言、这似乎相当不错、但我看到的主要问题是生成的代码大小比等效的 C 程序大4-5倍！ 映射文件显示其中的一个重要部分是 TI 运行时库代码。
示例项目只利用静态分配的对象,所以在映射文件中看到 free()函数是有点令人惊讶的! 进一步研究发现、以下论坛主题描述了与我看到的一个类似的场景： https://e2e.ti.com/support/tools/code-composer-studio-group/ccs/f/code-composer-studio-forum/785744/compiler-msp430fr5989-why-is-malloc-and-associated-functions-being-pulled-into-my-build?ReplyFilter=Answers&ReplySortBy=Answers&ReplySortOrder=Descending
这篇文章出自~5年前、TI C++编译器的状态也有所进步、支持 C++14标准(或对于 MSP430架构而言是可行的)、因此、我希望能够做更多的工作来减小生成的代码大小。 例如,检测程序从不返回的困难被引用为对 free()的调用(包括前面调用 free()的函数调用)无法被优化的原因。 但 C++11引入了[[noreturn]]属性，以显式将函数标记为从不返回。 在 main ()函数上使用此属性,我能够看到代码生成工具能够检测 main 是否返回/不返回,这意味着这个特定限制可能不再有效。
更深入地探索 C++内存使用情况还可观察到一些其他观察结果。
- 映射文件中存储器配置部分的 FRAM 使用情况摘要看起来与映射文件中其他位置的值不一致、例如模块摘要部分的总计
- CCS 的内存分配实用程序似乎也与自身发生冲突。 FRAM 总用量与中包含的段大小的总和不匹配
我尝试了同时使用 LC_SD 和 SC_SD 存储器模型进行构建、在这两种情况下、FRAM 的总数都比其中列出的段之和大864字节(0x0360)。
这是报告的 FRAM 使用总量问题吗、或者映射文件/内存分配实用程序中是否未报告此问题？
从编译的 C 程序的映射文件来看、这些数字似乎更接近我的预期、而且内存分配实用程序编号的加起来完全符合我的预期、这表明工具没有处理 C++的细微差别。
同时,我还尝试了固化调用 free()的函数,正如我所链接的线程中所建议的那样。 不幸的是、正如线程中所预测的那样、库已经移动、并且建议的残桩不再阻止 malloc/free 在我的编译项目中被调用。
- 我非常感谢您深入了解这是否是一项可以改进的功能、因为 C++可以帮助我们的新软件平台变得更简单、更容易实现。
- 一些关于如何存根库代码以防止 free()函数(和支持 callees)被编译到最终可执行文件的更新指导也是非常有用的,这样我就可以继续我的技术评估。
在相关方面、可以看到 TI 对实验性 LLVM MSP430后端的一些官方支持确实令人欣慰： https://github.com/llvm/llvm-project/tree/main/llvm/lib/Target/MSP430、TI 和 Clang-ARM CGT 似乎已经获益匪浅。 拥有标准化工具可以大大简化开发人员的工作、同时使我们能够以更少的工作量采用现代的 CI/CD 开发实践。
我们将不胜感激。
非常感谢。
凡妮萨
