MIPS架构:NOP(无操作)与危险预防中的数据转发

时间:2014-02-15 07:23:54

标签: mips computer-architecture

我在计算机体系结构课程中学到,通过在两个相互依赖的指令之间使用几个任意的,独立的nop指令,可以防止数据危害。这可以在编译器设计中的汇编级别完成。

避免数据危害的另一种方法是使用数据转发。

我有点困惑,就性能,速度和硬件而言,这两种选择有何不同。因为根据我的知识,数据转发将在硬件级别实现,而nop可以在汇编级别实现。

如果我们考虑性能,速度,硬件等因素,请大家解释一下哪种方法更好? 感谢。

2 个答案:

答案 0 :(得分:3)

显然,让编译器将nops插入到代码流中以填充管道槽,可以简化硬件,从而减少管道阶段的持续时间或管道的深度,减少设计工作量(上市时间,项目风险,设计成本),或允许一个完整的处理器内核适合单个芯片(这有助于性能)。 然而,与不使用转发的性能损失相比,这种好处很小。相关指令的较高延迟对于典型程序来说非常糟糕。

MIPS R2000延迟了分支延迟加载,提供了结果转发功能。 (MIPS is an acronym for "Microprocessor without Interlocked Pipeline Stages")。很快就从MIPS中删除了延迟加载(这是可能的,因为这样做不会影响正确代码的二进制兼容性)。延迟指令的使用部分源于这样的信念:大多数延迟时隙可以由编译器用有用的指令填充,并且部分地认为代码大小的增加相对于硬件的简化并不重要。

减少加载操作的延迟是不切实际的,因此无论如何都需要将管道停顿一段时间。 nop的成本是缓存和内存容量效应(即代码密度较低的影响),在某些情况下可以填充单个加载延迟槽。

公开管道组织也会影响二进制兼容性。以后的二进制兼容实现必须适应为原始管道组织设计的ISA。单个延迟分支槽对于simple 5-stage scalar实现工作得相当好(它可以在大多数时间填充有用的指令并允许零有效延迟分支[即,没有停顿来解决分支或预测和刷新错误预测的管道]),但是当管道加深(或变得更宽)时,无论如何都需要预测或停止。

如果目标工作负载中存在足够的并行性,硬件简单性非常重要,二进制兼容性不是问题,那么暴露管道,对动态检测和处理停顿条件的支持最小可能是明智的。 (还有一些编码nops的方法可以避免大多数代码大小扩展问题。)具有可靠的足够并行性(无论是指令级还是线程级)都可以避免nops;通过带有指令级并行性的编译器调度或通过线程级并行的硬件线程交错。

硬件简单性往往会降低每单位工作(以及芯片面积)的能耗,许多现代设计受到电源使用的限制。在编译时执行优化也是有意义的(当它们对延迟关键性较小并且可以执行一次而不是每次执行代码时)如果其他信息的存储和通信成本不是太高昂贵(假设在编译时可以获得执行优化所需的信息[动态分支预测是动态信息有用的经典示例]。)

答案 1 :(得分:1)

好吧,基本上由于硬件是通过前馈转发进行优化的,因此不必使用明确声明的软件NOP。但事实并非如此。 虽然,饲料转发证明有助于减少数据危害,但一些危害无法处理饲料转发。这是不可能的。
例如。

  1. beq R1,R5,label
  2. 指令第二
  3. 这里,在指令1完成执行阶段并决定是否分支之前,不会获取指令2nd。在那之前,第二条指令必须停止。 (停顿2个记忆周期)。这是通过软件发送NOP来完成的。 随着技术和硬件优化的改进,beq指令可以通过在fetch阶段本身插入比较器来完成其寄存器提取/解码阶段的执行阶段。即便如此,第2条指令也将停止(现在为1个存储周期)。再次需要NOP。