当我阅读RISC-V用户级ISA手册时，我注意到它说“OpenRISC具有条件代码和分支延迟槽，这使得更高性能的实现复杂化。”所以RISC-V没有分支延迟槽RISC-V User-Level ISA manual link。此外，Wikipedia表示大多数较新的RISC设计都省略了分支延迟槽。为什么大多数较新的RISC架构会逐渐省略分支延迟槽？
引用Hennessy和Patterson（计算机体系结构和设计，第5版）
谬误：你可以设计一个完美的建筑。 所有架构设计都涉及在一组硬件和软件技术的背景下进行的权衡。随着时间的推移，这些技术可能会发生变化，而在制定这些技术时可能做出的决定看起来就像是错误。 （...）RISC阵营中的一个例子是延迟分支。用五级管道控制管道危险是一件简单的事情，但对于管道较长且每个时钟周期发出多个指令的处理器来说，这是一个挑战。
实际上，就软件而言，延迟分支仅具有缺点，因为它使得程序更难以阅读并且效率更低，因为槽经常被nop填充。
在硬件方面，这是一项技术决策，在八十年代有一定意义，当时管道是5或6级，并且没有办法避免一个周期分支惩罚。
但目前，管道要复杂得多。最近的pentiumμarchitectures上的分支惩罚是15-25个周期。因此，一个指令延迟分支是无用的，并且显然不可能尝试用15指令延迟分支隐藏该延迟槽（这将破坏指令集的兼容性）。
我们开发了新技术。分支预测是一项非常成熟的技术。对于目前的分支预测器，误预测远远低于具有无用（nop）延迟时隙的分支的数量，因此即使在6周期计算机（如nios-f）上也更有效。
因此，延迟分支在硬件和软件方面效率较低。没理由保留它们。
延迟槽仅对短的有序标量流水线有用，而不是高性能超标量流，或者特别是有无序执行的流量槽。
它们显着地使异常处理复杂化（对于硬件和软件），因为如果延迟槽中的指令出现异常，则需要记录当前程序计数器和单独的下一个PC地址。
分支延迟槽在架构上暴露了有序经典RISC流水线的实现细节，以便在这种uarch上实现性能，但其他任何东西都必须解决它。如果你的uarch是classic RISC，它只能避免从被采用的分支中获取代码（即使没有分支预测）。
即使是现代有序的uarch也需要分支预测以获得良好的性能，内存延迟（以CPU时钟周期测量）远远高于早期MIPS时代。
编译器不能总是最佳地填充分支延迟槽，因此即使我们可以在高性能CPU中实现它们而没有显着的开销，它们也会在每条指令完成的总工作量方面降低成本。程序通常需要在ISA中执行更多指令，而不是更少的指令。
（虽然有时在比较和分支之后做一些无条件的事情可以允许重用寄存器而不需要新的寄存器，但在ISA上没有像MIPS这样的标志，其中分支指令直接测试整数寄存器。）