IAR编译器优化对程序的影响.pdfVIP

IAR 编译器优化对程序的影响 Qiao Jie 的邮箱secondjet1980@ IAR 编译器在不同的优化程度下，对函数执行效率有巨大的影响！根据网上的资料，IAR 确实在程序优化方面，比其他的编译器更为出色，其代码大小优化的能力甚至比ARM 自己 推出的RealView 编译器还要强，推测其速度优化能力也应该不弱。 我们在进行编程时，如没有特殊情况都应选择优化，建议： 1. 一般在编程开始时即使用Speed 最高优化； 2. 如Speed 最高优化运行时产生问题再将优化等级降低； 3. 只有当Flash 无法容纳程序时，再适当选择Balanced 或Size 优化； 4. 当高度优化导致某些语句被优化掉，此时进行bug 调试时可以选择None 优化。 以下是一个关于delay 函数的优化例子，表中列出了不同优化级别下，程序的理论运行 周期。 延时函数： void delay(u32 N) { u32 i = 0; for(i = 0; i N; i++); } 测试程序为一个死循环中运行delay ： while(1) { delay(1); delay(10); delay(100); delay(1000); delay(10000); } 周期 优化级别 delay(1) delay(10) delay(100) delay(1000) delay(10000) None 23 77 617 6017 60017 Size(High) 20 74 613-617(1) 6014 60014 Balanced(High) 8 8 8 8 8 Speed(High) 3(2) 3(2) 3(2) 3(2) 3(2) （1）优化造成函数语句跳转，出现多种周期； （2 ）优化造成5 行语句只能设置一个断点。 由上表中可以看出，None 优化时 delay(X) 的运行周期是6*X+17，Size(High)优化后约为 6*X+14，而Balanced(High)和Speed(High)优化后，周期数锐减且不随参数X 的值变化！ 产生的问题： 函数在优化之前和优化后，delay 函数的运行周期完全没有比例性，在高度 Speed 或 Balanced 优化后，delay 函数将会紊乱！ 解决方法： STM32 在 IAR 下编程，库函数中并不提供如__delay_cycles 这样的函数，因此只能自己 编写函数，可能的解决方法： （1）使用系统嘀嗒进行延时，但比较复杂在此不涉及； （2 ）是可以对现有函数进行修改来获得改进。 下面对延时函数进行修改并观察其效率。 A ．延时函数改为： void delay(u32 N) { u32 i = 0; for(i = 0; i N; i++) asm(nop); } 在函数中嵌入了一个汇编语句asm(nop)，这一句话也可以单独用在其他场合，作用是 精确延时一个时钟周期，使用相同的测试程序，结果如下表。 周期 优化级别 delay(1) delay(10) delay(100) delay(1000)