为什么我的代码在使用 Realview 工具构建时表现不佳，但使用 Codesourcery 构建时表现更好？
我有一个 C 项目，之前是使用 Codesourcery 的 gnu 工具链构建的。最近它被转换为使用 Realview 的 armcc 编译器，但是与使用 gnu 工具编译时相比，我们使用 Realview 工具获得的性能非常差。难道不应该是相反的情况，即使用 Realview 工具编译时应该提供更好的性能吗？我在这里缺少什么。如何使用 Realview 工具提高性能？
我还注意到，如果我使用 Lauterbach 运行 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
Lauterbach 问题已解决。这是由于半主机引起的，因为半主机 SWI 没有在 Lauterbach 环境中处理。重新定位 C 库以避免半主机成功了，现在我的程序可以在 Lauterbach 和 Realview ICE 上成功运行。但性能问题就是这样。
I have a C project which was previously being built with Codesourcery's gnu tool chain. Recently it was converted to use Realview's armcc compiler but the performance that we are getting with Realview tools is very poor compared to when it is compiled with gnu tools. Shouldnt it be opposite case i.e it should give better performance when compiled with Realview's tools? What am I missing here. How can I improve the performance with Realview's tools?
Also I have noticed that if I run the binary produced by Realview Tools with Lauterbach it crashes but If I run it using Realview ICE it runs fine.
UPDATE 1
Realview Command line:
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 command line:
arm-none-eabi-gcc -mcpu=arm1136jf-s
-mlittle-endian -msoft-float -O3 -Wall
I am using Realview Tools version 4.1 and GCC version 4.4.1
UPDATE 2
Lauterbach issue has been solved. It was being caused because of Semihosting as the semihosting SWI was not being handled in Lauterbach environment. Retargeting the C library to avoid Semihosting did the trick and now my program runs successfully with Lauterbach as well as Realview ICE. But the performance issue is as it is.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
由于您进行了优化，并且在某些环境中它会崩溃，因此您的代码可能使用未定义的行为或其他潜在错误。这种行为可能会随着优化而改变，甚至完全破坏。
我建议您在没有优化的情况下尝试这两个工具链，并确保警告级别设置为高，然后将它们全部修复。 GCC 在错误检查方面比armcc 好得多，因此是一种合理的静态分析检查。如果代码构建干净，它就更有可能工作，并且优化器可能更容易处理。
Since you have optimisations on, and in some environments it crashes, it may be that your code uses undefined behaviour or other latent error. Such behaviour can change with optimisation, or even break altogether.
I suggest that you try both tool-chains without optimisation, and make sure that the warning level is set high, and you fix them all. GCC is far better that armcc at error checking so is a reasonable static analysis check. If the code builds clean it is more likely to work and may be easier for the optimiser to handle.
您是否尝试过删除“--no_unaligned_access”？ ARM11 通常可以执行未对齐访问（如果在启动代码中启用），并且强制编译器/库不执行这些操作可能会降低代码速度。
Have you tried removing the '--no_unaligned_access'? ARM11s can typically do unaligned access (if enabled in the startup code) and forcing the compiler/library to not do them may be slowing down your code.
RVCT 的当前版本提到“--fpu=SoftVFP”：
这对我来说意味着，如果您可能有旧版本的 RVCT，则无论是否存在硬件浮点，其行为都将使用软件浮点。而在 GNU 版本中，当 FPU 可用时，-msoft-float 将使用硬件浮点指令。
那么您使用的是哪个版本的 RVCT？
无论哪种方式，我建议您删除
--fpu选项，因为编译器将根据所选的--cpu选项做出隐式的适当选择。您还需要更正 CPU 选择，您的 RVCT 选项显示--cpu=ARM1136J-S而不是您告诉 GCC 的 ARM1136FJ-S。这无疑会阻止编译器生成 VFP 指令，因为您告诉它它没有 VFP。The current version of RVCT says of '--fpu=SoftVFP':
This suggests to me that if you perhaps have an old version of RVCT the behaviour will be to use software floating point regardless of the presence of hardware floating point. While in the GNU version -msoft-float will use hardware floating point instructions when an FPU is available.
So what version of RVCT are you using?
Either way I suggest that you remove the
--fpuoption since the compiler will make an implicit appropriate selection based on the--cpuoption selected. You also need to correct the CPU selection, your RVCT option says--cpu=ARM1136J-Snot ARM1136FJ-S as you told GCC. This will no doubt prevent the compiler from generating VFP instructions, since you told it it has no VFP.由于诸如此类的因素，相同的源代码可能会产生截然不同的二进制文件。不同的编译器（llvm 与 gcc、gcc 4 与 gcc3 等）。同一编译器的不同版本。如果相同的编译器，则不同的编译器选项。优化（在任一编译器上）。编译用于发布或调试（或任何您想使用的术语，二进制文件完全不同）。当进行嵌入式时，您会添加引导加载程序或 ROM 监视器（调试器）等复杂功能。然后添加与 ROM 监视器对话或在调试器中编译的主机端工具。尽管是比 gcc 更好的编译器，arm 编译器仍然受到二进制文件始终在其 rom 监视器之上运行的假设的影响。我想记住，当 rvct 成为他们的主要编译器时，这个假设已经被淘汰，但从那时起我就没有真正使用过他们的工具。
最重要的是，有一些主要因素会影响二进制文件之间的差异，这些差异可能并且将会导致不同的体验。假设您将获得相同的性能或结果，这是一个错误的假设，预期结果会有所不同。同样，在同一环境中，您应该能够创建提供截然不同的性能结果的二进制文件。全部来自相同的源代码。
The same source code can produce dramatically different binaries due to factors like. Different compilers (llvm vs gcc, gcc 4 vs gcc3, etc). Different versions of the same compiler. Different compiler options if the same compiler. Optimization (on either compiler). Compiled for release or debug (or whatever terms you want to use, the binaries are quite different). When going embedded, you add in the complication of a bootloader or rom monitor (debugger) and things like that. Then add to that the host side tools that talk to the rom monitor or compiled in debugger. Despite being a far better compiler than gcc, arm compilers were infected with the assumption that the binaries would always be run on top of their rom monitor. I want to remember that by the time rvct became their primary compiler that assumption was on its way out, but I have not really used their tools since then.
The bottom line is there are a handful of major factors that can affect the differences between binaries that can and will lead to a different experience. Assuming that you will get the same performance or results, is a bad assumption, the expectation is that the results will differ. Likewise, within the same environment, you should be able to create binaries that give dramatically different performance results. All from the same source code.
您是否在 CodeSourcery 版本中启用了编译器优化，但在 Realview 版本中未启用？
Do you have compiler optimizations turned on in your CodeSourcery build, but not in the Realview build?