embedded - 为什么我的代码在使用 Realview 工具构建时表现不佳，但在 Codesourcery 中表现更好？

Question

我有一个 C 项目，之前是使用 Codesourcery 的 gnu 工具链构建的。最近它被转换为使用 Realview 的 armcc 编译器，但与使用 gnu 工具编译相比，我们使用 Realview 工具获得的性能非常差。不应该是相反的情况，即使用 Realview 的工具编译时它应该提供更好的性能吗？我在这里想念什么。如何使用 Realview 的工具提高性能？

我还注意到，如果我使用劳特巴赫运行 Realview Tools 生成的二进制文件，它会崩溃，但如果我使用 Realview ICE 运行它，它运行良好。

更新 1

Realview 命令行：

armcc -c --diag_style=ide --depend_format=unix_escaped --no_depend_system_headers --no_unaligned_access --c99 --arm_only --debug --gnu --cpu=ARM1136J-S --fpu=SoftVFP --apcs=/nointerwork - O3-Otime

GNU GCC 命令行：

arm-none-eabi-gcc -mcpu=arm1136jf-s -mlittle-endian -msoft-float -O3 -Wall

我正在使用 Realview Tools 4.1 版和 GCC 4.4.1 版

更新 2

劳特巴赫问题已解决。这是由于半主机导致的，因为在劳特巴赫环境中未处理半主机 SWI。重新定位 C 库以避免 Semihosting 成功了，现在我的程序可以在 Lauterbach 和 Realview ICE 上成功运行。但是性能问题就是这样。

Answer 1

由于您进行了优化，并且在某些环境中它会崩溃，因此可能是您的代码使用了未定义的行为或其他潜在错误。这种行为可以随着优化而改变，甚至完全中断。

我建议您在没有优化的情况下尝试这两个工具链，并确保将警告级别设置为高，然后将它们全部修复。GCC 在错误检查方面比 armcc 好得多，因此是一种合理的静态分析检查。如果代码构建干净，它更有可能工作，并且可能更容易让优化器处理。

Answer 2

您是否尝试过删除“--no_unaligned_access”？ARM11 通常可以进行非对齐访问（如果在启动代码中启用），并且强制编译器/库不这样做可能会减慢您的代码速度。

Answer 3

当前版本的RVCT 表示“--fpu=SoftVFP”：

在先前版本的 RVCT 中，如果您指定 --fpu=softvfp 和具有隐式 VFP 硬件的 CPU，则链接器会选择使用 VFP 指令实现软件浮点调用的库。这已不再是这种情况。如果您需要此传统行为，请使用 --fpu=softvfp+vfp。

这向我表明，如果您可能拥有旧版本的 RVCT，则行为将是使用软件浮点，而不管是否存在硬件浮点。在 GNU 版本中，当 FPU 可用时，-msoft-float 将使用硬件浮点指令。

那么您使用的是哪个版本的 RVCT？

无论哪种方式，我都建议您删除该--fpu选项，因为编译器将根据--cpu所选选项进行隐式适当的选择。您还需要更正 CPU 选择，您的 RVCT 选项--cpu=ARM1136J-S不是您告诉 GCC 的 ARM1136FJ-S。这无疑会阻止编译器生成 VFP 指令，因为您告诉它它没有 VFP。

Answer 4

由于诸如此类的因素，相同的源代码可能会产生截然不同的二进制文件。不同的编译器（llvm 与 gcc、gcc 4 与 gcc3 等）。同一编译器的不同版本。如果编译器相同，则编译器选项不同。优化（在任一编译器上）。为发布或调试而编译（或您想要使用的任何术语，二进制文件完全不同）。嵌入时，您添加了引导加载程序或 ROM 监视器（调试器）之类的复杂功能。然后添加与 rom 监视器对话或在调试器中编译的主机端工具。尽管是一个比 gcc 好得多的编译器，但 arm 编译器还是被假定二进制文件总是在它们的 rom 监视器上运行的假设所感染。我想记住，当 rvct 成为他们的主要编译器时，这种假设正在消失，

最重要的是，有一些主要因素会影响二进制文件之间的差异，这些差异会导致不同的体验。假设您将获得相同的性能或结果，这是一个糟糕的假设，期望结果会有所不同。同样，在相同的环境中，您应该能够创建具有显着不同性能结果的二进制文件。全部来自相同的源代码。

Answer 5

您是否在 CodeSourcery 构建中打开了编译器优化，但在 Realview 构建中没有？