用于处理两个分支结果的流水线处理器设计答案

【问题标题】：Pipeline Processor Design to handle both branch outcomes用于处理两个分支结果的流水线处理器设计
【发布时间】：2020-08-07 05:21:39
【问题描述】：

所以我最近一直在研究流水线处理器架构，主要是在 Y86-64 的背景下。在那里，我刚刚阅读了有关分支预测的内容，以及如何在错误预测分支的情况下，必须刷新获取、解码和执行流水线寄存器，并且必须处理新的正确分支指令。

我想知道是否有可能实际设计一个硬件，可能有 2 组流水线寄存器，这样当它获取条件指令时，它开始并行处理两个结果，更新一组寄存器，就好像分支会不发生，另一组好像分支会发生。

值得注意的是，如果一个或两个分支又导致指令本身也是一个分支指令，那么问题就出现了，那么 2 组是不够的。但是由于当第一个分支条件到达执行阶段时，我们将知道实际采取哪个分支，因此我们可以消除错误分支及其所有子分支。而且由于第一个分支指令从 Fetch 到 Execute 阶段需要 3 个时钟周期，我认为在最坏的情况下，我们只需要 2^3，即 8 组流水线寄存器。

除了在硬件方面实施起来有点困难之外，我认为这种方法可行的假设有什么问题吗？或者这可能已经在 X86-64 等更复杂的架构中完成了？

谢谢。

【问题讨论】：

我也想过这个。我想这很困难，因为解码器是 CPU 逻辑的重要组成部分，复制它会占用大量内存空间。
@fuz 正如你所说，这会导致明显的空间问题，但是除了空间限制之外还有什么可以阻止这个问题的解决吗？
@dkapur17：如果没有分支，会浪费多少 CPU 资源？可能的答案是“它可以全速完成这两种结果，因此在没有分支的情况下浪费了一半的 CPU 资源”（多核对于 CPU 资源的性能/利用率会更好）； “它可以以较低的速度完成这两种结果，因此当没有分支时，只有不到一半的 CPU 资源被浪费了”（SMT 在性能方面会更好）和“它可以以一半的速度完成这两种结果，因此没有 CPU 的资源是浪费了”（根本没有任何好处）。
@Brendan，是的......这似乎是一个有效的观点！
相关：Why not just predict both branches?。但真正要记住的是，你可以用什么else来打开那个死区和电源。例如4 宽的超标量/乱序执行，以及一个很好的分支预测器。请参阅Modern Microprocessors A 90-Minute Guide! 您基本上有 8 个管道，大部分是 8 核 CPU（减去互连和数据缓存一致性......以及 8 个慢速标量核心）。如果它们是真正独立的，那么指令获取/I-cache 读取端口将成为更大的问题

标签： assembly x86 cpu-architecture branch-prediction micro-architecture

【解决方案1】：

就 RISC 与 CISC 架构而言，我记得后者尝试的技术大致类似于您在 1980 年代末/1990 年代初建议的技术。检查维基百科的分支预测分析 没有文章，但在 RSA（加密）文章中重定向到 this，该文章描述了一种利用 branch predictor 帮助找到私有加密密钥的技术。它还提到了同时多线程作为加速分支预测的一种方式。

要更直接地解决您的问题，请参阅simultaneous multithreading 中的详细信息部分。一般来说，这似乎是一个正在进行的研究和分歧的领域。

【讨论】：

这看起来很有趣。我一定会读一读的。谢谢！
分支预测侧通道是对确实选择一种方式的预测器的定时攻击，因此当他们选择错误时会变慢。 OP 提出的设计将击败这一点，但普通的无分支代码也是如此。（避免数据依赖分支，我的意思是。你仍然需要依赖于密钥大小的循环等等。）
@dkapur17：SMT（例如超线程）降低了所有停顿的吞吐量成本（通过保持管道提供来自另一个线程的其他工作）。这与硬件分支的想法有些相关，因为您正在运行来自具有复制寄存器文件的 2 个程序计数器的代码，但 SMT 让它们真正独立：内核看起来像操作系统的两个 CPU。