数据依赖和控制依赖的区别
我正在努力理解数据依赖和控制依赖之间的区别。
所以我看到的一个例子是：
数据依赖性，例如，指令使用另一条指令创建的数据
控制依赖性，例如，指令等待更新的reg进行比较
我很难理解的是，例如在beq，我等待登记簿更新，但我也依赖于他的数据。
所以我不知道如何知道它们之间的区别。
共有1个答案
指令等待更新reg进行比较是对控件依赖项的错误描述，难怪
在检查分支条件之前，条件分支指令本身对其输入寄存器具有数据依赖性。
分支后的指令对分支具有控件依赖关系。前端需要根据是否执行了分支，知道要获取/解码哪些指令。（或对于间接分支，目标地址是什么）。
分支预测进行猜测，稍后可能会发现是错误的。（当分支指令实际执行并检查预测时）。
在简单（标量）顺序管道中，依赖指令无法在分支指令到达exec阶段之前到达。发现分支预测失误并从中恢复只意味着重新引导前端从正确的地址提取，丢弃从错误路径提取（并解码）的指令。
但在乱序执行CPU中可能会发生这种情况。尤其是如果分支的输入是长依赖链的一部分，但对其具有控制依赖关系的指令没有数据依赖关系。（即它们是乱序后端可以推测性地开始的独立工作。）
当预测正确时，分支预测推测执行可有效隐藏控制依赖关系。这就是为什么如果（a==0）返回a，编译器通常会转换<代码> 进入<代码>中 和类似；如果它们仍要进行分支（控件依赖关系），请使用返回值打破/避免代码的数据依赖关系。
相关：
>
当skylake CPU预测失误时，会发生什么情况？-现代OoO exec CPU。
通过提前计算条件来避免管道停滞-最小化分支本身的数据依赖链长度，因此它可以提前执行并验证分支预测。
依赖链分析提到了循环分支的控制依赖关系。
CPU预测和内存障碍-推测性执行通过分支可能会导致内存重新排序。
为什么条件移动不易受到分支预测失败的影响？-CMOV纯粹是一个ALU select操作，只是一个数据依赖项，而不是控件依赖项。
- gcc优化标志-O3使代码比-O2慢，显示了CMOV如何变慢，从而创建了一个循环携带的数据依赖链，而不是推测执行可以隐藏的控制依赖
-
我想知道以下jar的所有传递依赖项： 将经典命令移动到pom。项目定义依赖关系和输入的xml： mvn依赖：树 将显示： 我没看到魔咒父母： 乍一看，mvn命令似乎可以显示非pom类型的依赖项。 有没有一种方法可以精确地显示使jar保持活动状态所需的每个文件？ 谢谢
-
定义取自此处 依赖性 一个类的结构或行为的更改会影响另一个相关的类，那么这两个类之间存在依赖关系。反之亦然。当一个类包含另一个类时，就会发生这种情况。 作文 组合是聚合的一种特例。以更具体的方式，受限聚合称为组合。当一个对象包含另一个对象时，如果包含的对象不能在没有容器对象存在的情况下存在，则称为组合。 这里和这里的Java具体例子 依赖性 作文
-
在阅读了很多关于这个问题的文章之后，并遵循了这个非常有用的帖子：在npmpackage.json文件中，依赖关系、devDependence和peerDependence之间有什么区别？ 我知道依赖项应该引用每个运行时libs，devdependency引用每个对开发依赖项有用的libs。 但是我现在很困惑。对于生产使用，我将不得不我的Angular应用程序。如果我做了，我甚至不能用编译。我需要，
-
2.1依赖注入和控制反转 Java应用程序-这是一个宽松的术语，它包括的范围从受限的嵌入式应用程序到n层的服务器端企业应用程序-通常组成程序的对象互相协作而构成正确的应用程序。因此，在一个应用程序中的对象彼此具有_依赖关系（dependencies）。_ 虽然Java平台提供了丰富的应用程序开发功能，但它缺乏将基本的模块组织成一个整体的方法，而将该任务留给了架构师和开发人员。虽然你可以使用如_工厂
-
2.1 依赖注入和控制反转 Java应用程序——范围从受限的、嵌入式的应用到N层的、服务器端的企业应用——通常由协作形成该程序的对象构成，因此一个应用程序中的对象彼此依赖。 虽然Java平台提供了大量的程序开发功能，但是它缺少将基础构建块组成一个整体的工具，而将此任务留给了架构师和开发者。尽管可以利用设计模式（比如Factory、Abstract Factory、Builder、Decorator
-
CocoaPods依赖库版本控制 默认最简单的导入方式 pod 'Moya' 锁定版本 使用逻辑运算符 > 0.1 Any version higher than 0.1 >= 0.1 Version 0.1 and any higher version < 0.1 Any version lower than 0.1 <= 0.1 Version 0.1 and any lower ver