哈哈哈，超酷汇编教程－－ 简明x86汇编语言教程(7).txt

学习(编程技巧_编程知识_程序代码),是学习编程不可多得的学习精验

jl SHORT nexti             ; i < 10, 再次循环
pop esi                    ; 恢复esi 

这段代码可能有些令人费解。主要是因为它不仅使用了大量寄存器，而且还包括了5.2节中曾提到的子表达式提取技术。表面上看，多引入的那个变量(t)增加了计算时间，但要注意，这个t不仅不会降低程序的执行效率，相反还会让它变得更快！因为同样得到了计算结果(本质上，i*j即是第j次累加i的值)，但这个结果不仅用到了上次运算的结果，而且还省去了乘法(很显然计算机计算加法要比计算乘法快)。

这里可能会有人问，为什么要从999循环到0，而不是按照程序中写的那样从0循环到999呢？这个问题和汇编语言中的取址有关。在下两节中我将提到这方面的内容。

5.4 x86体系结构上的并行最大化和指令封包
考虑这样的问题，我和两个同伴现在在山里，远处有一口井，我们带着一口锅，身边是树林；身上的饮用水已经喝光了，此处允许砍柴和使用明火(当然我们不想引起火灾:)，需要烧一锅水，应该怎么样呢？

一种方案是，三个人一起搭灶，一起砍柴，一起打水，一起把水烧开。

另一种方案是，一个人搭灶，此时另一个人去砍柴，第三个人打水，然后把水烧开。

这两种方案画出图来是这样：



仅仅这样很难说明两个方案孰优孰劣，因为我们并不明确三个人一起打水、一起砍柴、一起搭灶的效率更高，还是分别作效率更高(通常的想法，一起做也许效率会更高)。但假如说，三个人一个只会搭灶，一个只会砍柴，一个只会打水(当然是说这三件事情)，那么，方案2的效率就会搞一些了。

在现实生活中，某个人拥有专长是比较普遍的情况；在设计计算机硬件的时候则更是如此。你不可能指望加法器不做任何改动就能去做移位甚至整数乘法，然而我们注意到，串行执行的程序不可能在同一时刻同时用到处理器的所有功能，因此，我们(很自然地)会希望有一些指令并行地执行，以充分利用CPU的计算资源。

CPU执行一条指令的过程基本上可以分为下面几个阶段：取指令、取数据、计算、保存数据。假设这4个阶段各需要1个时钟周期，那么，只要资源够用，并且4条指令之间不存在串行关系(换言之这些指令的执行先后次序不影响最终结果，或者，更严格地说，没有任何一条指令依赖其他指令的运算结果)指令也可以像下面这样执行：

指令1 取指令 取数据 计　算 存数据 　 　 　 
指令2 　 取指令 取数据 计　算 存数据 　 　 
指令3 　 　 取指令 取数据 计　算 存数据 　 
指令4 　 　 　 取指令 取数据 计　算 存数据 

这样，原本需要16个时钟周期才能够完成的任务就可以在7个时钟周期内完成，时间缩短了一半还多。如果考虑灰色的那些方格(这些方格可以被4条指令以外的其他指令使用，只要没有串行关系或冲突)，那么，如此执行对于性能的提升将是相当可观的(此时，CPU的所有部件都得到了充分利用)。

当然，作为程序来说，真正做到这样是相当理想化的情况。实际的程序中很难做到彻底的并行化。假设CPU能够支持4条指令同时执行，并且，每条指令都是等周期长度的4周期指令，那么，程序需要保证同一时刻先后发射的4条指令都能够并行执行，相互之间没有关联，这通常是不太可能的。

最新的Intel Pentium 4-XEON处理器，以及Intel Northwood Pentium 4都提供了一种被称为超线程(Hyper-Threading TM)的技术。该技术通过在一个处理器中封装两组执行机构来提高指令并行度，并依靠操作系统的调度来进一步提升系统的整体效率。

由于线程机制是与操作系统密切相关的，因此，在本文的这一部分中不可能做更为深入地探讨。在后续的章节中，我将介绍Win32、FreeBSD 5.x以及Linux中提供的内核级线程机制(这三种操作系统都支持SMP及超线程技术，并且以线程作为调度单位)在汇编语言中的使用方法。

关于线程的讨论就此打住，因为它更多地依赖于操作系统，并且，无论如何，操作系统的线程调度需要更大的开销并且，到目前为止，真正使用支持超线程的CPU，并且使用相应操作系统的人是非常少的。因此，我们需要关心的实际上还是同一执行序列中的并发执行和指令封包。不过，令人遗憾的是，实际上在这方面编译器做的几乎是肯定要比人好，因此，你需要做的只是开启相应的优化；如果你的编译器不支持这样的特性，那么就把它扔掉……据我所知，目前在Intel平台上指令封包方面做的最好的是Intel的C++编译器，经过Intel编译器编译的代码的性能令人惊异地高，甚至在AMD公司推出的兼容处理器上也是如此。

5.5 存储优化
从前一节的图中我们不难看出，方案2中，如果谁的动作慢，那么他就会成为性能的瓶颈。实际上，CPU也不会像我描述的那样四平八稳地运行，指令执行的不同阶段需要的时间(时钟周期数)是不同的，因此，缩短关键步骤(即，造成瓶颈的那个步骤)是缩短执行时间的关键。

至少对于使用Intel系列的CPU来说，取数据这个步骤需要消耗比较多的时间。此外，假如数据跨越了某种边界(如4或8字节，与CPU的字长有关)，则CPU需要启动两次甚至更多次数的读内存操作，这无疑对性能构成不利影响。

基于这样的原因，我们可以得到下面的设计策略：


程序设计中的内存数据访问策略

尽可能减少对于内存的访问。在不违背这一原则的前提下，如果可能，将数据一次处理完。 
尽可能将数据按4或8字节对齐，以利于CPU存取 
尽可能一段时间内访问范围不大的一段内存，而不同时访问大量远距离的分散数据，以利于Cache缓存*
 

第一条规则比较简单。例如，需要求一组数据中的最大值、最小值、平均数，那么，最好是在一次循环中做完。

“于是，这家伙又攒了一段代码”……

int a[]={1,2,3,4,5,6,7,8,9,0,1,2,3,4,5,6,7,8,9,0};
int i;
int avg, max, min; 
avg=max=min=a[0];

for(i=1; i<(sizeof(a)/sizeof(int)); i++){
  avg+=a[i];
  if(max < a[i])
    max = a[i];
  else if(min > a[i])
    min = a[i];
}

avg /= i;
 

Visual C++编译器把最开始一段赋值语句翻译成了一段简直可以说是匪夷所思的代码：

; int a[]={1,2,3,4,5,6,7,8,9,0,1,2,3,4,5,6,7,8,9,0};

mov edi, 2                         ; 此时edi没有意义
mov esi, 3                         ; esi也是！临时变量而已。
mov DWORD PTR _a$[esp+92], edi
mov edx, 5                         ; 黑名单加上edx
mov eax, 7                         ; eax也别跑:)
mov DWORD PTR _a$[esp+132], edi
mov ecx, 9                         ; 就差你了，ecx

; int i;
; int avg, max, min;
; avg=max=min=a[0];

mov edi, 1                         ; edi摇身一变，现在它是min了。
mov DWORD PTR _a$[esp+96], esi
mov DWORD PTR _a$[esp+104], edx
mov DWORD PTR _a$[esp+112], eax
mov DWORD PTR _a$[esp+136], esi
mov DWORD PTR _a$[esp+144], edx
mov DWORD PTR _a$[esp+152], eax
mov DWORD PTR _a$[esp+88], 1       ; 编译器失误? 此处edi应更好
mov DWORD PTR _a$[esp+100], 4
mov DWORD PTR _a$[esp+108], 6
mov DWORD PTR _a$[esp+116], 8
mov DWORD PTR _a$[esp+120], ecx
mov DWORD PTR _a$[esp+124], 0
mov DWORD PTR _a$[esp+128], 1
mov DWORD PTR _a$[esp+140], 4
mov DWORD PTR _a$[esp+148], 6
mov DWORD PTR _a$[esp+156], 8
mov DWORD PTR _a$[esp+160], ecx
mov DWORD PTR _a$[esp+164], 0
mov edx, edi                       ; edx是max。
mov eax, edi                       ; 期待已久的avg, 它被指定为eax 

这段代码是最优的吗？我个人认为不是。因为编译器完全可以在编译过程中直接把它们作为常量数据放入内存。此外，如果预先对a[0..9]10个元素赋值，并利用串操作指令(rep movsdw)，速度会更快一些。

当然，犯不上因为这些问题责怪编译器。要求编译器知道a[0..9]和[10..19]的内容一样未免过于苛刻。我们看看下面的指令段：

; for(i=1; ...

mov esi, edi
for_loop:

; avg+=a[i];

mov ecx, DWORD PTR _a$[esp+esi*4+88]
add eax, ecx

; if(max < a[i])

cmp edx, ecx
jge SHORT elseif_min

; max = a[i];

mov edx, ecx

; else if(min > a[i])

jmp SHORT elseif_min
elseif_min:
cmp edi, ecx
jle SHORT elseif_end

; min = a[i];
mov edi, ecx

elseif_end:

; [for i=1]; i<20; i++){

inc esi
cmp esi, 20
jl SHORT for_loop

; }
; avg /= i;

cdq
idiv esi 

; esi: i




; ecx: 暂存变量, =a[i]
; eax: avg



; edx: max








; 有趣的代码...并不是所有的时候都有用
; 但是也别随便删除
; edi: min









; i++
; i与20比较






; avg /= i 

上面的程序倒是没有什么惊人之处。唯一一个比较吓人的东西是那个jmp SHORT指令，它是否有用取决于具体的问题。C/C++编译器有时会产生这样的代码，我过去曾经错误地把所有的此类指令当作没用的代码而删掉，后来发现程序执行时间没有明显的变化。通过查阅文档才知道，这类指令实际上是“占位指令”，他们存在的意义在于占据那个地方，一来使其他语句能够正确地按CPU觉得舒服的方式对齐，二来它可以占据CPU的某些周期，使得后续的指令能够更好地并发执行，避免冲突。另一个比较常见的、实现类似功能的指令是NOP。

占位指令的去留主要是靠计时执行来判断。由于目前流行的操作系统基本上都是多任务的，因此会对计时的精确性有一定影响。如果需要进行测试的话，需要保证以下几点：


计时测试需要注意的问题

测试必须在没有额外负荷的机器上完成。例如，专门用于编写和调试程序的计算机 
尽量终止计算机上运行的所有服务，特别是杀毒程序 
切断计算机的网络，这样网络的影响会消失 
将进程优先级调高。对于Windows系统来说，把进程(线程)设置为Time-Critical; 对于*nix系统来说，把进程设置为实时进程 
将测试函数运行尽可能多次运行，如10000000次，这样能够减少由于进城切换而造成的偶然误差 
最后，如果可能的话，把函数放到单进程的系统(例如FreeDOS)中运行。
 

对于绝大多数程序来说，计时测试是一个非常重要的东西。我个人倾向于在进行优化后进行计时测试并比较结果。目前，我基于经验进行的优化基本上都能够提高程序的执行性能，但我还是不敢过于自信。优化确实会提高性能，但人做的和编译器做的思路不同，有时，我们的确会做一些费力不讨好的事情。