keil优化等级设置

Posted 2020-10-17 壹点灵异

Compiler optimization levels and the debug view

4.3 Compiler optimization levels and the debug view

The precise optimizations performed by the compiler depend both on the level of optimization chosen, and whether you are optimizing for performance or code size.

The compiler supports the following optimization levels:

 

0

Minimum optimization. Turns off most optimizations. When debugging is enabled, this option gives the best possible debug view because the structure of the generated code directly corresponds to the source code. All optimization that interferes with the debug view is disabled. In particular:

• Breakpoints can be set on any reachable point, including dead code.
• The value of a variable is available everywhere within its scope, except where it is uninitialized.
• Backtrace gives the stack of open function activations that is expected from reading the source.

Note

Although the debug view produced by -O0 corresponds most closely to the source code, users might prefer the debug view produced by -O1 because this improves the quality of the code without changing the fundamental structure.

Note

Dead code includes reachable code that has no effect on the result of the program, for example an assignment to a local variable that is never used. Unreachable code is specifically code that cannot be reached via any control flow path, for example code that immediately follows a return statement.

1

Restricted optimization. The compiler only performs optimizations that can be described by debug information. Removes unused inline functions and unused static functions. Turns off optimizations that seriously degrade the debug view. If used with --debug, this option gives a generally satisfactory debug view with good code density.

The differences in the debug view from –O0 are:

• Breakpoints cannot be set on dead code.
• Values of variables might not be available within their scope after they have been initialized. For example if their assigned location has been reused.
• Functions with no side-effects might be called out of sequence, or might be omitted if the result is not needed.
• Backtrace might not give the stack of open function activations that is expected from reading the source because of the presence of tailcalls.

The optimization level –O1 produces good correspondence between source code and object code, especially when the source code contains no dead code. The generated code can be significantly smaller than the code at –O0, which can simplify analysis of the object code.

2

High optimization. If used with --debug, the debug view might be less satisfactory because the mapping of object code to source code is not always clear. The compiler might perform optimizations that cannot be described by debug information.

This is the default optimization level.

The differences in the debug view from –O1 are:

• The source code to object code mapping might be many to one, because of the possibility of multiple source code locations mapping to one point of the file, and more aggressive instruction scheduling.
• Instruction scheduling is allowed to cross sequence points. This can lead to mismatches between the reported value of a variable at a particular point, and the value you might expect from reading the source code.
• The compiler automatically inlines functions.

3

Maximum optimization. When debugging is enabled, this option typically gives a poor debug view. ARM recommends debugging at lower optimization levels.

If you use -O3 and -Otime together, the compiler performs extra optimizations that are more aggressive, such as:

• High-level scalar optimizations, including loop unrolling. This can give significant performance benefits at a small code size cost, but at the risk of a longer build time.
• More aggressive inlining and automatic inlining.

These optimizations effectively rewrite the input source code, resulting in object code with the lowest correspondence to source code and the worst debug view. The --loop_optimization_level=option controls the amount of loop optimization performed at –O3 –Otime. The higher the amount of loop optimization the worse the correspondence between source and object code.

For extra information about the high level transformations performed on the source code at –O3 –Otime use the --remarks command-line option.

Because optimization affects the mapping of object code to source code, the choice of optimization level with -Ospace and -Otime generally impacts the debug view.

The option -O0 is the best option to use if a simple debug view is required. Selecting -O0 typically increases the size of the ELF image by 7 to 15%. To reduce the size of your debug tables, use the --remove_unneeded_entities option.

 

官网链接

优化级别说明（仅供参考）：
则其中的 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的介绍,我建议大家看看以下的文章,它的解释非常详尽。

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

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

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

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