IAR的编译器比MDK的差这么多?!

只看该作者 · 2008-4-9 18:06

One ELF section per function的意思是，把每个函数做成一个section，以便在链接时去除没有用到的函数。IAR里面不需要这个选项，因为IAR的linker本来就被设计成(缺省情况下)不链接没有用到的函数，所以不需要把每个函数做成一个section这么麻烦。
楼主遇到的代码大小差异，很可能与编译器本身没有关系，而是在IAR里包含了某些只在调试时用到的库，例如EWARM版本4里的runtime control modules, I/O emulation modules,或版本5里的semihosted library，等等，可以仔细查看一下配置。
顺便说一下，如果在代码里调用了printf, vsprintf等I/O库函数，在IAR里可以把它们设置较为精简的版本（例如少支持几种字符串格式），从而急剧减小代码；这是其它工具里都没有见过的。

只看该作者 · 2008-4-10 10:10

跑dhrystone一秒多少循环。优化级别不一样，结果也不一样。最多快约一倍。
看来IAR编译器效率还是不如原厂ARM的。
keil：
-O0:43662   fortime 43662
-O1:53730   fortime 79119
-02:54960   fortime 98090
-O3:53650   fortime 99858
iar ：
none 26191
-low 27016
-m   56425
-h   71427（forspeed）

只看该作者 · 2008-4-10 10:20

《RealView MDK应用开发入门》一书已由北航出版社出版了，向北航就可以订得到，另外新华书店也可以买到了。

另外基于STM32的书也很快要出版了，大概在5月份吧！

只看该作者 · 2008-4-10 10:23

我又试了几个例程,结果差不多,我看了一下反汇编,感觉IAR缺省也没有去除冗余函数

只看该作者 · 2008-4-10 12:36

你用的是EWARM v4.xx吧？不能拿IAR的老版本和Keil的新版本比啊，升级到EWARM v5看看，差异是很小的。
另外，dhrystone是个很不靠谱的测试程序。仔细跟一下就会发现，dhrystone里绝大多数时间是在运行strcpy和strcmp这两个库函数，造成的结果是，dhrystone其实没有比较编译器性能或硬件性能，而是在比较这两个库函数谁写得好......专业的性能评测现在一般都用EEMBC，结果会客观得多。

只看该作者 · 2008-4-10 13:17

《RealView MDK应用开发入门》一书已由北航出版社出版了，向北航就可以订得到，另外新华书店也可以买到了。

没有啊

只看该作者 · 2008-4-10 15:31

我两个编译器都用的最新版本KEIL3.20,IAR5.11
另外dhrystone靠不靠普，也不是象你说的那样，我其他实验也做过，结果和这个差不多（差距是有的，而且也不很小），只不过是自己程序不好有说服力。

只看该作者 · 2008-4-16 17:53

我也做也一下实验，MDK确实好许多，编译效果必IAR的好多了，生成的文件也小很多！！！让我的那个用IAR的兄弟郁闷了半天。。。。

只看该作者 · 2009-9-22 22:04

但IAR也很牛的

只看该作者 · 2009-9-23 00:58

诶，可惜MDK的免费版本8符合偶这里的要求。。。。。。

只看该作者 · 2009-9-23 06:30

本帖最后由 void_c 于 2009-9-23 06:33 编辑

无代码，无真相。

只看该作者 · 2009-9-23 09:11

瞧这坟挖的.................

只看该作者 · 2009-9-23 10:43

IAR对于新手入门比较难,需要设置的东西太多.好在IAR提供的文档比较全面,只要把它的几个PDF文件仔细看一遍,基本上没有什么问题了.IAR的界面也不怎么符合一般人的习惯,不过多用用就好了.keil要友好很多,但对工程师而言,不就是看看几个寄存器和变量,这方面都差不多的.

1万 · 2009-9-23 11:26

如果设置选项丰富，可以让使用者可以按照自己的需要精确地控制编译器环境的设置。

如果设置选项简洁，可以让不是很了解的用户摆脱设置工具的烦恼，快速上手。

这好比专业摄影师往往喜欢手动调节相机的参数，而一般的人只需要一个自动的傻瓜相机就足矣。不同的人有不同的需要，不同的工具因不同的需要复杂度也不一样，但只要熟练应用，都可以得到好的效果。

只看该作者 · 2009-9-23 11:51

PLS注意：IAR是一家瑞典公司！
另外对于现在STM32的代码空间来讲，编译效率对代码大小的影响似乎不能被引起足够的重视，我觉得更应该重视的是软件执行速度和BUG的多少，有些程序优化级别太高的话反而不能正常运行，这点我是深有体会，尤其是KEIL C51，优化级别绝对不能太高，感觉KEIL的历史文化底蕴还是比IAR要差很多，他的名气大部分是C51换来的，所谓的原厂，你敢说流明被TI收购之后出的M3就是TI原厂的么？挂牌而已