GitBook: [#17] No subject

part5-ji-suan-ji-xi-tong-jia-gou-de-jin-yi-bu-you-hua/chapter20-zhi-ling-ji-bing-hang-ji-shu/20.1-ilp-ji-ben-gai-nian.md

@@ -35,7 +35,7 @@ for (int i =0; i <= 999; i++)
 1. 前后指令使用了相同的寄存器，使得指令之间存在**数据依赖**关系；
 2. 存在大量跳转指令，使得我们必须执行完跳转指令后才能确定接下来执行的指令，因此指令间还存在**控制依赖**。这一方面跳转指令会拖慢流水线执行效率，还有分支预测错误的可能，另一方面还会使得基本块太小，使得后文介绍的动态调度的空间非常有限。
 
-当然根据我们在流水线一章中学习的内容，结构冒险也是潜在的瓶颈之一，但在以上两个问题严重的情况下，结构冒险的问题便不再突出，毕竟同一时刻能同时执行的指令十分有限。突破上述瓶颈的方案将会在后续章节讲解，这一两小节将为后文的分析引入一些基本概念。
+当然根据我们在流水线一章中学习的内容，结构冒险也是潜在的瓶颈之一，但在以上两个问题严重的情况下，结构冒险的问题便不再突出，毕竟同一时刻能同时执行的指令十分有限。突破上述瓶颈的方案将会在后续章节讲解，这一两小节将为后文的分析引入一些基本概念，由此我们可以认识到，怎样的指令之间并行性会受限。
 
 #### 数据依赖（data dependence）
 
@@ -50,27 +50,34 @@ Loop:
     bne    x1, x2, Loop   // 直到 x1 = x2 不再继续
 ```
 
-学过流水线数据冒险的我们我们不难发现，加入上述代码在简单的顺序执行流水线CPU上运行，
+学过流水线数据冒险的我们我们不难发现，假如上述代码在简单的顺序执行流水线CPU上运行，
 
 ```nasm
 fld    f0, 0(x1)
 fadd.d f4, f0, f2
 ```
 
-这一代码片段中存在一个关于寄存器f0的数据冒险——因为加法指令的源操作数中用到了上一条指令的目的寄存器，因此我们需要通过前递机制来解决这一冒险。
+这一代码片段中存在一个关于寄存器f0的数据冒险——因为加法指令的源操作数中用到了上一条指令的目的寄存器，由此我们便引入第一种指令依赖关系——数据依赖。我们称**指令**$$j$$**数据依赖于指令**$$i$$**（我们称指令**$$j$$**为依赖方，指令**$$i$$**为被依赖方）**，如果
 
-#### 命名依赖（name dependence）
+1. 指令$$j$$需要指令$$i$$产生的结果作为其源操作数；
+2. 指令$$j$$数据依赖于指令$$k$$，指令$$k$$数据依赖于指令$$i$$。
 
+事实上我们已经十分熟悉上面这种递归式的定义，1中的描述说明了数据依赖产生的base case，2中的描述表明数据依赖可以形成一个“数据依赖链”，这个链条的长度甚至可以贯穿整个程序。
 
+定义数据依赖后有一个很显然的意义，即存在数据依赖的两条指令之间必须（即使两条指令在数据依赖链条中距离较远也必须如此，可以思考其中原因）依照源程序规定的执行顺序执行，否则无法确保依赖方源操作数的准确性，因此我们的动态调度、静态调度技术需要检测出这种依赖，并保证顺序执行。
 
-#### 控制依赖（control dependence）
+还有一点需要强调的是，我们在定义的第一条中并没有限制数据依赖必须是使用了相同寄存器，实际上**访问同样的内存地址也是符合定义的**。但是这增大了检测依赖的难度，因为同一个内存地址可以有不同表达方式，例如可以表示为0(x1)，也可以表示为-12(x2)，这便增大了检测难度。在后续章节中我们会详细讲解现在的技术如何解决这一较为复杂的问题。
+
+#### 命名依赖（name dependence）
 
 
 
-#### 依赖与冒险的关系
+#### 数据冒险（data hazard）
 
 实际上，我们在前文中多次提及依赖与冒险这两个词，我们十分有必要说明这两个词的关系与差别，以免产生混淆。
 
+#### 控制依赖（control dependence）
+
 
 
 <img alt="" class="gitbook-drawing">