ARM Cortex-M 编译器差异 [英] ARM Cortex-M compiler differences

问题描述

我将要为我的项目使用 C 语言为 STM32 处理器上的 Cortex-M 内核开发一些固件，并在网上搜索我发现了很多不同的编译器:Keil、IAR、Linaro、Yagarto 和 ARM 嵌入式处理器的 GNU 工具.

I'm about to develop some firmwares for Cortex-M cores on STM32 processors using C for my projects, and searching on the web I've found a lot of different compilers: Keil, IAR, Linaro, Yagarto and GNU Tools for ARM Embedded Processors.

我想知道，这些编译器之间有哪些功能差异可能会影响我的选择?例如，作为发烧友，我不需要供应商的支持或帮助，目前对代码大小进行限制是可以的.此外，易用性也不是主要问题，因为我喜欢学习(目前我拥有配置和运行 GNU ARM 的 Keil Lite 和 Eclipse).

I was wondering, what functional differences are there between these compilers that might influence my choice? For example as an enthusiast I don't need support or assistance from the vendor, and a limitation on the code size is OK for the moment. Also the ease of use is not a main concern since I like to learn (and for the moment I have both Keil Lite and Eclipse with GNU ARM configured and working).

这些编译器之间生成的代码在大小/速度方面是否如此不同?有对比表吗?(我只在网上找到过时的信息)

Is the generated code so different in terms of size/speed between these compilers? Are there any comparison table? (I've found only stale infos on the web)

推荐答案

基准测试本身就是一种艺术形式，通常很容易操纵结果以显示您想要的任何内容.除了非常小的测试用例外，我不希望编译器生成相同的结果，有时在这些小测试用例中，它们的结果要么相同，要么有时大不相同，因为您的测试暴露了一个编译器知道/使用的优化，一个编译器知道/使用其他没有.

benchmarking is an artform in and of itself, usually easy to manipulate the results to show whatever you want. I would not expect the compilers to generate the same results except for very small test cases, and sometimes in those small test cases their results are either identical or sometimes vastly different as your test has exposed an optimization that one compiler knows/uses and one the other doesnt.

例如，我曾经使用 dhrystone 跟踪此类事情(编译器性能数字)，但是在已知基准测试的情况下(不是 dhrystone 意味着更多，而是其他)，您可能会发现一些编译器正在调整自己以查看在基准下表现良好，可能会以牺牲其他东西为代价.

I used to keep track of such things (compiler performance numbers) with dhrystone for example, but in the case of known benchmarks (not that dhrystone means much anymore, but others) you may find that some compilers are tuning themselves to look good under benchmarks perhaps at the expense of something else.

没有正确的答案，没有普遍的最好"，这一切都在旁观者的眼中，你.哪个工具对您来说更容易使用，您更喜欢哪个工具，无论是 gui 还是漂亮的颜色或声卡声音等等.然后从那里开始.

There is no right answer, there is no universal "best", it is all in the eye of the beholder, you. Which tool is easier for you to use, which do you like better be it for the gui or pretty colors or sound card sounds or whatever. And go from there.

通常用于我测试过的应用程序的 gnu 编译器不会生成快速"的代码，这是我的基准，与其他人相比，但是有更多的人使用免费的 gnu 工具，因此对它的支持要广泛得多到网页、论坛和示例的数量.gnu 也没有大小限制，但它可能需要更多的学习或任何东西来启动和运行......

The gnu compiler generally for applications I have tested does not produce code as "fast" which is my benchmark, compared to the others, but there are way more people using the free gnu tools so the support for it is considerably wider due to the number of web pages and forums and examples. gnu wont have a size restriction either, but it may require more learning or whatever to get up and running...

cortex-ms分为armv6m和armv7m家族，v6m(cortex-m0)只有少量的thumb2扩展，armv7m有大约150个thumbv2扩展到thumb，所以你需要知道你的工具是什么支持而不是在错误的芯片上使用错误的东西.那么编译器如果知道所有这些，就可能并且将从相同的源代码中产生不同的指令混合.在使用不同命令行选项的同一编译器或系列中，您可以/将获得截然不同的代码.除此之外，如果你有一个带有缓存的 cortex-m4，如果你有这样的东西，取决于代码在缓存行中的位置，你可能会获得截然不同的性能，所以基准测试本身就是一个针对每个 blob 的研究项目您要进行基准测试的 C 代码.单个编译器内的性能范围可能会影响另一个编译器，或者重叠可能足以无关紧要.

The cortex-ms are split into the armv6m and armv7m families, the v6m (cortex-m0) only have a small number of thumb2 extensions, the armv7m have about 150 thumbv2 extensions to thumb, so you need to know what your tools support and not use the wrong stuff on the wrong chip. Then the compilers if they know all of this may and will produce different instruction mixes from the same source code. Further within the same compiler or family using different command line options you can/will get vastly different code. And then beyond that with a cortex-m4 with cache on if you have one with such a thing, depending on how the code lies in the cache lines you may get vastly different performance, so benchmarking is a research project in itself for each blob of C code you want to benchmark. The performance range within a single compiler may shadow another compiler or the overlap may be enough to not matter.

如果您可以使用这些工具，通过学习使用竞争工具并能够走进工作和/或在您的工作中，选择您认为适合工作的工具或走进去，从而专业地为自己增加价值基尔的房子，可以立即工作，或牛牛的房子，可以立即工作.如果您只是 gnu 并且这份工作是为 Kiel 房子准备的，那么您可能会失去工作.

If you have access to the tools you add value to yourself professionally by learning to use the competing tools and being able to walk into a job and or within your job choose what you see as the right tool for the job or walk into a Kiel house and be able to work right away or a gnu house and work right away. Where you might lose a job if you are gnu only and the job is for a Kiel house.

这篇关于ARM Cortex-M 编译器差异的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！