keil优化等级设置

转自:http://www.ndiy.cn/archiver/tid-6041.html

优化级别说明(仅供参考):
则其中的 Code Optimization    栏就是用来设置C51的优化级别。共有9个优化级别(书上这么写的),高优化级别中包含了前面所有的优化级别。现将各个级别说明如下:

0级优化:
1、 常数折叠:只要有可能,编译器就执行将表达式化为常数数字的计算,其中包括运行地址的计算。
2、 简单访问优化:对8051系统的内部数据和位地址进行访问优化。
3、 跳转优化:编译器总是将跳转延至最终目标上,因此跳转到跳转之间的命令被删除。
1级优化:
1、 死码消除:无用的代码段被消除。
2、 跳转否决:根据一个测试回溯,条件跳转被仔细检查,以决定是否能够简化或删除。
2级优化:
1、 数据覆盖:适于静态覆盖的数据和位段被鉴别并标记出来。连接定位器BL51通过对全局数据流的分析,选择可静态覆盖的段。
3级优化:
1、“窥孔”优化:将冗余的MOV命令去掉,包括不必要的从存储器装入对象及装入常数的操作。另外如果能节省存储空间或者程序执行时间,复杂操作将由简单操作所代替。
4级优化:
1、 寄存器变量:使自动变量和函数参数尽可能位于工作寄存器中,只要有可能,将不为这些变量保留数据存储器空间。
2、扩展访问优化:来自IDATA、XDATA、PDATA和CODE区域的变量直接包含在操作之中,因此大多数时候没有必要将其装入中间寄存器。
3、局部公共子式消除:如果表达式中有一个重复执行的计算,第一次计算的结果被保存,只要有可能,将被用作后续的计算,因此可从代码中消除繁杂的计算。
4、 CASE/SWITCH语句优化:将CASE/SWITCH语句作为跳转表或跳转串优化。
5级优化:
1、 全局公共子式消除:只要有可能,函数内部相同的子表达式只计算一次。中间结果存入一个寄存器以代替新的计算。
2、 简单循环优化:以常量占据一段内存的循环再运行时被优化。
6级优化:
1、 回路循环:如果程序代码能更快更有效地执行,程序回路将进行循环。
7级优化:
1、 扩展入口优化:在适合时对寄存器变量使用DPTR数据指针,指针和数组访问被优化以减小程序代码和提高执行速度。
8级优化:
1、 公共尾部合并:对同一个函数有多处调用时,一些设置代码可被重复使用,从而减小程序代码长度。
9级优化:
1、 公共子程序块:检测重复使用的指令序列,并将它们转换为子程序。C51甚至会重新安排代码以获得更多的重复使用指令序列。
当然,优化级别并非越高越好,应该根据具体要求适当选择。 




Keil C51总线外设操作问题的深入分析
    阅读了《单片机与嵌入式系统应用》2005年第10期杂志《经验交流》栏目的一篇文章《Keil C51对同一端口的连续读取方法》(原文)后,笔者认为该文并未就此问题进行深入准确的分析 文章中提到的两种解决方法并不直接和简单。笔者认为这并非是Keil C51中不能处理对一个端口进行连续读写的问题,而是对Kei1 C51的使用不够熟悉和设计不够细致的问题,因此特撰写本文。
    本文中对原文提到的问题,提出了三种不同于原文的解决方法。每种方法都比原文中提到的方法更直接和简单,设计也更规范。(无意批评,请原文作者见谅)

1 问题回顾和分析
    原文中提到:在实际工作中遇到对同一端口反复连续读取,Keil C51编译并未达到预期的结果。原文作者对C编译出来的汇编程序进行分析发现,对同一端口的第二次读取语句并未被编译。但可惜原文作者并未分析没有被编译的原因,而是匆忙地采用一些不太规范的方法试验出了两种解决办法。
    对此问题,翻阅Keil C51的手册很容易发现:KeilC51的编译器有一个优化设置,不同的优化设置,会产生不同的编译结果。一般情况缺省编译优化设置被设定为8级优化,实际最高可设定为9级优化:

1. Dead code elimination。
2.Data overlaying。
3.Peephole optimization。
4.Register variables。
5.Common subexpression elimination。
6.Loop rotation。
7.Extended Index Access Optimizing。
8.Reuse Common Entry Code。
9.Common Block Subroutines。
    而以上的问题,正是由于Keil C51编译优化产生的。因为在原文程序中将外设地址直接按如下定义:
unsigned char xdata MAX197 _at_ 0x8000
    采用_at_将变量MAX197定义到外部扩展RAM 指定地址0x8000。因此,Keil C51优化编译理所当然认为重复读第二次是没有用的,直接用第一次读取的结果就可以了,因此编译器跳过了第二条读取语句。至此,问题就一目了然了。

2 解决方法
由以上分析很容易就能提出很好的解决办法。
2.1 最简单最直接的办法
    程序一点都不用修改,将Keil C51的编译优化选择设置为0(不优化)就可以了。选择project窗口的Target,然后打开“Options for Target”设置对话框,选择“C51”选项卡,将“Code Optimiztaion”中的“Level”选择为“0:Costant folding”。再次编译后,大家会发现编译结果为:
CLR MAXHBEN
MOV DPTR,#MAX197
MOVX A,@DPTR
MOV R7,A
MOV down8,R7
SETB MAXHBEN
MOV DPTR,#MAX197
MOVX A,@DPTR
MOV R7,A
MOV up4,R7
两次读取操作都被编译出来了。

2.2 最好的方法
    告诉Keil C51,这个地址不是一般的扩展RAM,而是连接的设备,具有“挥发”特性,每次读取都是有意义的。可以修改变量定义,增加“volatile”关键字说明其特征:
unsigned char volatile xdata MAX197 _at_ 0x8000;
    也可以在程序中包含系统头文件;“#include<absacc.h>”,然后在程序中修改变量,定义为直接地址:
#define MAX197 XBYTE
    这样,Keil C51的设置仍然可以保留高级优化,且编译结果中,同样两次读取并不会被优化跳过。

2 3 硬件解决方法
    原文中将MAX197的数据直接连接到数据总线,而对地址总线并未使用,采用一根端口线选择操作高低字节。很简单的修改方法就是使用一根地址线选择操作高低字节即可。比如:将P2.0(A8)连接到原来P1.0连接的HBEN脚(MAX197的5脚).在程序中分别定义高低字节的操作地址:
unsigned char volatile xdata MAX197_L _at_ 0x8000;
unsigned char volatile xdata MAX197_H _at_ 0x8100;
将原来的程序:
MAXHBEN =0;
down8=MAX197;//读取低8位
MAXHBEN =1;
up4=MAX197;//读取高4位
改为以下两句即可
down8= MAX197_L;//读取低8位
up4=MAX197_H;//读取高4位

3 小结
    Keil C51经过长期考验和改进以及大量开发人员的实际使用,已经克服了绝大多数的问题,并且其编译效率也非常高。对于一般的使用.很难再发现什么问题。笔者曾经粗略研究过一下Keil C51优化编洋的结果.非常佩服Keil C51设计者的智慧,一些C程序编译产生的汇编代码.甚至比一般程序员直接用汇编编写的代码还要优秀和简练 通过研读Kell C51编译产生的汇编代码.对提高汇编语言编写程序的水平都是很有帮助的。
    由本文中的问题可以看出:在设计中遇到问题时.一定不要被表面现象蒙蔽,不要急于解决,应该认真分析,找出问题的原因.这样才能从根本上彻底解决问题。

附表:Keil C51中的优化级别及优化作用 级别         说明
0         常数合并:编译器预先计算结果,尽可能用常数代替表达式。包括运行地址计算。
优化简单访问:编译器优化访问8051系统的内部数据和位地址。
跳转优化:编译器总是扩展跳转到最终目标,多级跳转指令被删除。
1         死代码删除:没用的代码段被删除。
拒绝跳转:严密的检查条件跳转,以确定是否可以倒置测试逻辑来改进或删除。
2         数据覆盖:适合静态覆盖的数据和位段被确定,并内部标识。BL51连接/定位器可以通过全局数据流分析,选择可被覆盖的段。
3         窥孔优化:清除多余的MOV指令。这包括不必要的从存储区加载和常数加载操作。当存储空间或执行时间可节省时,用简单操作代替复杂操作。
4         寄存器变量:如有可能,自动变量和函数参数分配到寄存器上。为这些变量保留的存储区就省略了。
优化扩展访问:IDATA、XDATA、PDATA和CODE的变量直接包含在操作中。在多数时间没必要使用中间寄存器。
局部公共子表达式删除:如果用一个表达式重复进行相同的计算,则保存第一次计算结果,后面有可能就用这结果。多余的计算就被删除。
Case/Switch优化:包含SWITCH和CASE的代码优化为跳转表或跳转队列。
5         全局公共子表达式删除:一个函数内相同的子表达式有可能就只计算一次。中间结果保存在寄存器中,在一个新的计算中使用。
简单循环优化:用一个常数填充存储区的循环程序被修改和优化。
6         循环优化:如果结果程序代码更快和有效则程序对循环进行优化。
7         扩展索引访问优化:适当时对寄存器变量用DPTR。对指针和数组访问进行执行速度和代码大小优化。
8         公共尾部合并:当一个函数有多个调用,一些设置代码可以复用,因此减少程序大小。
9         公共块子程序:检测循环指令序列,并转换成子程序。Cx51甚至重排代码以得到更大的循环序列。




优化论

谈到优化,其实很多人都哭笑不得,因为在一个C51软件工程师的生涯中,总要被KEIL的优化耍那么一次到几次。我被耍过,想必看着文章的你也被耍过,如果你回答说不,那只能说你写的C51程序不多!
看看KEILC的优化级别选项吧:


0-9共10个级别的优化,0是最低,9最高,一个普通的程序,设置最高级别和最低级别,编译后代码量有时会相差很远,以DX板DEMO程序为例,0级优化后是14K的CODE,9级优化后是10K的CODE,前后相差了4K。可见这个差别是多么的大。
事实上我们不需要知道对应的各个级别KEIL会如何优化你的程序或优化了些什么,我们只需要以一种严谨的态度去编写和对待你的程序就可以了。在我个人的观念中,程序在9级优化后依然能保持完美无误的运行,你才算了解KEIL的脾气。
好了,还是说点正点的:
有些人习惯整体程序都选择同一个优化级,事实上每个C文件都可以有独立的优化级别的:

在工作区右键选择你的模块(.C)然后选取Options for File xxx就会出现如下界面:


在C51选项中就可以选择优化级别和警告级别等东西了,被独立设置过的C文件会有特殊的标记的:


用以提醒你这个文件的编译处理并非默认设置!
如果你觉得模块优化都不够细的话,你可以考虑局部优化,也就是说对某个函数实行某个级别的优化。当你发现9级优化的时候某个函数总是变的不正常,但你又希望其它函数和程序段保持最高的简洁度,那么局部优化可以说是相当有用的了。在KEIL手册中有介绍这个功能:
#pragma OPTIMIZE(x) x就是你希望的优化级别,一般应用如下:

#pragma OPTIMIZE(6)
void FunA()
{
}
......
......

#pragma OPTIMIZE(9)
void FunB()
{
}

上面的意思就是说,在void FunA()到void FunB()之前的所有函数,包括FunA在内,都采用6级的优化,而从FunB开始直到之后,只要没碰上#pragma OPTIMIZE,都采用9级优化了。
OPTIMIZE还可以多一个参数,就是speed和size,
用法: #pragma OPTIMIZE(9,speed)或#pragma OPTIMIZE(5,size)
对应的就是9级优化,以速度为主,或5级优化,以空间最小为主。

4.StartUp.a51
在之前第一节的建立工程中就曾经提到过StartUp.a51这个东西了,就是在工程初建的时候有个对话框用于选择是否为工程添加这个a51文件。


其实这个文件给大家最最深刻的感觉就是:开机清空RAM。事实上它还有其他特别的用途的,例如初始化堆栈(很多人不知道KEILC一开始把堆栈设定为多少,事实上可以通过软件仿真的时候从这个文件找到答案),然后是再入函数的虚拟堆栈的设置,还有更高级一点的,BANK的初始化。
旧版本KEIL自动为每个工程默认添加相同的StartUp文件,后期的KEIL就有了上图的选择,如果选择添加,则会为每个工程添加一个独立的StartUp。用户可以通过手工改写StartUp.a51实现某些必要的上电初始化。例如最通常的:取消单片机开机清RAM功能!!
关于STARTUP的介绍,我建议大家看看以下的文章,它的解释非常详尽。

##################################

在实际使用时发现仿真时有写程序是白色的无法进行断点设置

搜索到的答案是优化等级过高,一些普通的程序被优化。

只得把优化程序等级降低。

### Keil 编译器不同优化等级导致的问题及解决方法 #### O0 无优化设置为 `O0` 优化等级时,编译器不对代码进行任何优化处理。这通常用于调试阶段,因为未经过优化的代码更容易理解和跟踪。 然而,在某些情况下,即使是在最低级别的优化下也可能出现问题。例如,如果开发者依赖于特定的指令顺序来实现硬件初始化或其他低级操作,则完全禁用优化可能不是最佳选择[^1]。 ```c // 使用 O0 优化等级可以防止编译器对这段代码做任何改动 #pragma optimize="0" void critical_section() { // 关键代码部分 } ``` #### O1 基本优化 在这一层次上,编译器会尝试简化表达式并移除冗余计算。虽然这些改进有助于提高性能,但也有可能改变程序的行为方式,特别是对于那些涉及复杂指针运算或依赖于具体机器特性的代码片段来说更为明显[^2]。 一种常见的情况是循环展开(Loop Unrolling),它能够减少分支预测失败次数从而加快执行速度;但是过度应用此技术反而会造成更大的开销甚至引发错误[^3]。 ```c for (int i = 0; i < N; ++i) { array[i] *= factor; } // 可能会被编译成多个连续乘法语句以加速运行时间 ``` #### O2 较强优化 到了 `O2` 层次之后,除了继续沿用之前提到过的各种策略之外,还会引入更多激进的技术比如内联函数调用、公共子表达式的提取以及跨过程间分析等等。尽管如此,随着优化程度加深也意味着潜在风险增加——尤其是针对嵌入式系统开发而言,不当使用的延迟函数可能会受到严重影响而无法正常工作[^4]。 实验表明,在 `-O2` 下测量得到的时间间隔变长了(107.6μs),这是因为编译器试图通过调整指令序列等方式提升效率却意外干扰到实际计时逻辑: ```c volatile unsigned long delay_count; void delay_us(unsigned int us) { volatile unsigned long start_time = get_timer_value(); while ((get_timer_value() - start_time) < us); } // 需要注意使用 volatile 来阻止不必要的优化影响延时准确性 ``` #### O3 最大化速度优化 最高级别的优化旨在尽可能地榨取目标平台上的每一分性能潜力。不过这也使得编写可移植性强且易于维护的应用变得更加困难,尤其是在面对诸如浮点数精度丢失等问题时尤为突出。 此外还有可能出现由于寄存器分配不合理而导致局部变量覆盖原有数据的情形,特别是在多线程环境中共享资源的情况下更是危险重重。 ```assembly ANL AUXR1, #01111111b ; software reset flag clear CLR EA ; disable interrupts globally before resetting MOV TA, #0AAh ; MOV TA, #55h ; specific sequence required by hardware design ORL CHPCON, #10000000b ; trigger system-wide restart via software command ``` 为了应对上述挑战,建议采取以下措施之一: - **利用汇编语言**:对于一些特别敏感的操作可以直接采用汇编指令完成,这样就能绕过高级编程语言层面所带来的不确定性因素。 - **适当降低优化级别**:根据实际情况灵活调整项目文件中的编译选项,默认保持较低水平直到确认所有功能均稳定为止再逐步升高直至满足需求为止。 - **谨慎运用 `volatile` 关键字**:确保每次读写都按照预期发生而不受缓存机制干扰,尤其适用于外部设备交互场合下的状态监测与控制命令发送环节。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值