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

Question

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

另外我注意到如果我运行Realview Tools生成的二进制文件与Lauterbach一起崩溃但是如果我使用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库以避免半主机功能，现在我的程序与Lauterbach以及Realview ICE成功运行。但性能问题仍然存在。

Answer 1

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

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

Answer 2

您是否尝试删除'--no_unaligned_access'？ ARM11通常可以进行未对齐访问（如果在启动代码中启用）并且强制编译器/库不执行它们可能会降低代码速度。

Answer 3

RVCT的当前版本说'--fpu = SoftVFP'：

  

在以前的RVCT版本中，如果你   指定--fpu = softvfp和一个带CPU的CPU   隐式VFP硬件，链接器   选择了一个实现了这个的库   软件浮点调用   VFP指令。这不再是   案子。如果你需要这个遗产   行为，使用--fpu = softvfp + vfp。

这告诉我，如果您可能拥有旧版本的RVCT，则无论是否存在硬件浮点，行为都将是使用软件浮点。在GNU版本中，当FPU可用时，-msoft-float将使用硬件浮点指令。

那你使用什么版本的RVCT？

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

Answer 4

由于类似因素，相同的源代码会产生截然不同的二进制文件。不同的编译器（llvm vs gcc，gcc 4 vs gcc3等）。不同版本的同一编译器。如果编译器相同，编译器选项不同。优化（在任一编译器上）。编译为发布或调试（或者您想要使用的任何术语，二进制文件是完全不同的）。进入嵌入式时，您会添加引导加载程序或ROM监视器（调试器）的复杂功能以及类似的内容。然后添加与rom监视器对话或在调试器中编译的主机端工具。尽管编译器是一个比gcc好得多的编译器，但是arm编译器被假设二进制文件总是在它们的rom监视器上运行。我想要记住，当rvct成为他们的主要编译器时，假设正在逐渐消失，但从那时起我就没有真正使用过他们的工具。

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

Answer 5

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