该代码有多少个真正的依赖关系？
LW t1, 0(t4) ; t1 ← address (0+t4)
ADDI t1, t1, #8 ; t1 ← t1+8
MULT t3, t1, t1 ; t3 ← t1*t1
SW t3, 4(t2) ; address(4+t2) ← t3
我目前无法分辨出该代码有多少个真正的依赖关系。对我来说，有两种看待它的方法。指令1（i1）对（i2）具有真正的依赖性，查看了第一个输出的T1，现在是下一个指令中的输入。但是，寄存器T1现在具有新值（I2之后）。我的问题是，是否只有一个真实的依赖性……是i2和i3（t1），还是i1和i3（t1）也被认为是真正的依赖性，即使T1被用作i2的输出？
LW t1, 0(t4) ; t1 ← address (0+t4)
ADDI t1, t1, #8 ; t1 ← t1+8
MULT t3, t1, t1 ; t3 ← t1*t1
SW t3, 4(t2) ; address(4+t2) ← t3
I'm currently unable to tell how many true dependencies this code has. For me, there are two ways of looking at it. Instruction 1 (I1) has a true dependency with (I2), looking at the t1 that was first the output and now the input in the next instruction. However, the register t1 now has a new value (after I2). My question is, is there only one more true dependency... that being I2 and I3 (t1) or is I1 and I3 (t1) also considered to be a true dependency even though t1 has been used as the output in I2?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
听起来您会混淆术语 depentency href =“ https://en.wikipedia.org/wiki/hazard_(computer_architecture）” rel =“ nofollow noreferrer”>危险。
真实或流动依赖性是将值分配给变量或存储的条件，并且该值已从同一变量或存储中读取/使用/消耗。＆nbsp;这是以高级语言和汇编语言/机器代码为基础的编程基本原则 - 程序员依靠这一点，并且经常写依赖。
重新分配变量或重新定位变量（在汇编中发生很多）时，旧值就会丢失，并且程序员的期望（以及架构的承诺）是，当稍后阅读时，新值是获得的。
因此，由于
t1是在i2上重新使用的，因此i1和i3之间的t1依赖关系不得。相比之下，危害是管道和其他高级处理器的内部实施问题。处理器实施必须观察指令设置的架构要求，无论内部实施详细信息如何，索赔都遵守，否则索赔是错误的，并且为指令集编写的软件在实施方面无法正常工作。
危害通常涉及各种依赖。＆nbsp;当依赖关系发生在较小的指令距离内时，一种非常明显的危害，原始的（读写后）发生在管道处理器中（例如，比（部分）管道的一部分短）。
Sounds like you're confusing the term dependency with the term hazard.
A true or flow dependency is condition where a value is assigned to a variable or storage earlier and that value is read/used/consumed from that same variable or storage later. This is a fundamental principle in programming, both in high level languages and assembly language/machine code — programmers rely on this, and frequently write dependencies.
When a variable is reassigned or register is repurposed (happens a lot in assembly) the old value is lost, and, the programmer's expectation (and architecture's promise) is that when later read, the new value is what is obtained.
Thus, since
t1is repurposed at I2 there can be not1dependency between I1 and I3.Hazards, by contrast, are internal implementation concerns of pipelined and other advanced processors. A processor implementation must observe the architectural requirements of the instruction set it claims adherence to, regardless of internal implementation details, or else the claim is false, and software written for the instruction set won't work properly on the implementation.
Hazards often involve various kinds of dependencies. One very notable hazard, RAW (read after write), happens in pipelined processors when dependencies occur within small instruction distances (e.g. shorter than (a portion of) the pipeline).