简明x86汇编语言教程(7)-编译优化
5.3 全局寄存器优化
[待修订内容] 本章中，从这一节开始的所有优化都是在微观层面上的优化了。换言之，这些优化是不能使用高级语言中的对应设施进行解释的。这一部分内容将进行较大规模的修订。
通常，此类优化是由编译器自动完成的。我个人并不推荐真的由人来完成这些工作——这些工作多半是枯燥而重复性的，编译器通常会比人做得更好(没说的，肯定也更快)。但话说回来，使用汇编语言的程序设计人员有责任了解这些内容，因为只有这样才能更好地驾驭处理器。
在前面的几章中我已经提到过，寄存器的速度要比内存快。因此，在使用寄存器方面，编译器一般会做一种称为全局寄存器优化的优化。
例如，在我们的程序中使用了4个变量：i, j, k, l。它们都作为循环变量使用：
| for(i=0; i<1000; i++){ for(j=0; j<1000; j++){ for(k=0; k<1000; k++){ for(l=0; l<1000; l++) do_something(i, j, k, l); } } } |
这段程序的优化就不那么简单了。显然，按照通常的压栈方法，i, j, k,l应该按照某个顺序被压进堆栈，然后调用do_something()，然后函数做了一些事情之后返回。问题在于，无论如何压栈，这些东西大概都得进内存(不可否认某些机器可以用CPU的Cache做这件事情，但Cache是写通式的和回写式的又会造成一些性能上的差异)。
聪明的读者马上就会指出，我们不是可以在定义do_something()的时候加上inline修饰符，让它在本地展开吗？没错，本地展开以增加代码量为代价换取性能，但这只是问题的一半。编译器尽管完成了本地展开，但它仍然需要做许多额外的工作。因为寄存器只有那么有限的几个，而我们却有这么多的循环变量。
把四个变量按照它们在循环中使用的频率排序，并决定在do_something()块中的优先顺序(放入寄存器中的优先顺序)是一个解决方案。很明显，我们可以按照l, k, j,i的顺序(从高到低，因为l将被进行1000*1000*1000*1000次运算！)来排列，但在实际的问题中，事情往往没有这么简单，因为你不知道do_something()中做的到底是什么。而且，凭什么就以for(l=0; l<1000;l++)作为优化的分界点呢？如果do_something()中还有循环怎么办？
如此复杂的计算问题交给计算机来做通常会有比较满意的结果。一般说来，编译器能够对程序中变量的使用进行更全面地估计，因此，它分配寄存器的结果有时虽然让人费解，但却是最优的(因为计算机能够进行大量的重复计算，并找到最好的方法;而人做这件事相对来讲比较困难)。
编译器在许多时候能够作出相当让人满意的结果。考虑以下的代码：
| int a=0; for(int i=1; i<10; i++) |
让我们把它变为某种形式的中间代码：
| 00: 0 -> a 01: 1 -> i 02: 1 -> j 03: i*j -> t 04: a+t -> a 05: j+1 -> j 06: evaluate j < 100 07: TRUE goto 03 08: i+1 -> i 09: evaluate i < 10 10: TRUE goto 02 11: [继续执行程序的其余部分] |
程序中执行强度最大的无疑是03到05这一段，涉及的需要写入的变量包括a, j;需要读出的变量是i。不过，最终的编译结果大大出乎我们的意料。下面是某种优化模式下Visual C++ 6.0编译器生成的代码(我做了一些修改)：
| xor eax, eax ; a=0(eax: a) mov edx, 1 ; i=1(edx: i) push esi ; 保存esi(最后要恢复，esi作为代替j的那个循环变量) nexti: mov ecx, edx ; [t=i] mov esi, 999 ; esi=999: 此处修改了原程序的语义，但仍为1000次循环。 nextj: add eax, ecx ; [a+=t] add ecx, edx ; [t+=i] dec esi ; j-- jne SHORT nextj ; jne 等价于 jnz. [如果还需要，则再次循环] inc edx ; i++ cmp edx, 10 ; i与10比较 jl SHORT nexti ; i < 10, 再次循环 pop esi ; 恢复esi |
这