本帖最后由 sinanjj 于 2010-8-7 15:42 编辑
Compiler optimization
编译器优化
Compiling for better performance
编译出更好的性能
The four basic optimization options offered by the GNU compiler are -O0,-O1,-O2 and -O3. These offer an increasing level of optimization such that -O0 carries out no optimization of the compiled code, whereas -O3 carries out the most optimization.
As the level of optimization increases, the compiler will attempt to produce better performing code. This may also have the effect of reducing the code size at levels -O1 and -O2 (compared to -O0).
However at level -O3, a number of additional optimization techniques are enabled which may produce higher performance code - but which are likely to also increase the code size.
gcc优化选项, -O0是不优化. -o3是优化的最厉害. 不过优化的最厉害的时候往往会增加体积. 所以...同志们看着办吧
With Code Red's tools suite, the Debug configuration defaults to building -O0, and the Release configuration defaults to either -O2 or-O3 (depending on which version of the tools suite you are using). You can modify the optimization option used by a particular build configuration as follows:
code red的工具(当然包括LPCXpresso )都是默认的 debug模式不优化 -o0, release模式优化为-O2或者-O3 , 具体看什么软件. 如果要改动这个优化. 按照下列操作.
1. Open the Project properties. There are a number of ways of doing this. For example, make sure the Project is highlighted in the Project Explorer view then open the menu "Project -> Properties".
2. In the left-hand list of the Properties window, open "C/C++ Build" and select "Settings" and then the "Tool Settings" tab.
3. Now choose "MCU C Compiler - Optimization" and select the required optimization level from the drop-down.
Compiling for better code size
优化出更小的代码
As noted earlier, the above options are focussed on improving the performance of your code. This will sometimes, but not always, also reduce code size. If code size is your primary focus, then there is an additional option that may be of use, the -Os. This enables all -O2 optimizations that do not typically increase code size, but also performs further optimizations designed to reduce code size.
You can modify the optimization option used by a particular build configuration to -Os by selecting "MCU C Compiler - Optimization" in Project Properties and entering -Os into the "Other optimization options" field.
减小代码优化选项 -Os, 一般都打开了.
具体情况多试试各个选项的结合.
Actual code size and performance
The code size and performance results you will obtain for your particular source code for a particular optimization level are very much dependent on both the source code and the system that the code is executed it. It is well worth compiling at a number of optimization levels and seeing which provides the result closest to your ideal balance of code size and performance. The optimization level number gives an indication as to what the heuristics within the compiler's optimization engine will try to achieve for an average system. They are not a guarantee of the actual result.
Optimized code fails to execute correctly
优化代码引起的运行失败
Although the reason why code built with optimization fails to run correctly is sometimes a fault with the compiler, quite often it is actually down to the way that your code is written is not "optimization friendly". The two of the most common causes of problems are:
优化代码以解决这一问题, 一下方法优化:
1. Where variables which map onto memory mapped peripheral devices have not been marked as 'volatile'. With a debug build, such code can often work, as the compiler does not optimize out memory access. But if such variables are not marked as 'volatile', a release build will often optimise them out. For more information, please see:
* http://en.wikipedia.org/wiki/Volatile_variable
* http://users.ece.utexas.edu/~val ... /chap4.htm#VOLATILE
一个硬件可以改变的变量没有volatile关键字声明. (这个一般是头文件的事. 非高手就不要乱改头文件了...)
2. Timing loops. When compiled for release, if you have loops which simply count up to a particular value, for example waiting for a configuration register to change, the count can often no longer be sufficient when the code is compiled for Release due to the additional optimisation. In addition, if the variables used in such loops are not marked as volatile, they may well be just optimized away!
Debugging of optimized code
调试优化过的代码
At -O0, one or more machine instructions can effectively be mapped onto a specific source statement. However as the level of optimization carried out by the compiler increases, the mapping between source code and the generated machine instructions becomes much more complex. For example, this may lead to instructions originally generated from a number of source lines being merged or reordered.
One of the consequences of this is that when debugging optimized code, program behavior can sometimes be different to what might be expected from just looking at the original source code.
For example a breakpoint set on the first source statement of a loop might only get hit once, as the actual breakpoint may have been set on an initialisation instruction that only executes the first time through the loop.
Another example is that sometimes stepping a single source statement may lead to the program stopping at the previous source statement - so that it appears that the program has executed backwards! However what has actually happened is that the next machine instruction is actually mapped to the previous source statement in the debug data (the part of the ELF image created by the compiler/link that is used by the debugger to map between source and executable).
When debugging your application, it can often therefore be sensible to debug using as low a level of optimization as possible (normally -O0) until you are sure that the program is correct algorithmically, and only then start to increase the optimization level.
(就是调试的时候别优化, 老老实实的用-O0 要不可能出奇怪问题)
And finally...
This article is very much an overview and only covers the top-level compiler options. There are a number of other compiler optimization that you might want to consider using in particular circumstances. For more information on these, please see the GCC documentation.
(其他问题参考gcc文档.--------本来就是gcc) |
楼主
标题置顶
标题高亮
