问题标签 [micro-architecture]

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

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

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

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

谢谢。

RIDL 漏洞利用需要攻击者触发页面错误才能从行填充缓冲区读取陈旧数据。但是根据关于 RIDL 漏洞和负载的“重放”，也可以使用辅助负载。

该问题九次提到辅助/辅助负载，但我仍然无法理解这种负载的作用或触发方式。这与 TLB 相关，并且“导致需要微码辅助的页面浏览”。

有人可以解释一下辅助/辅助负载是什么，最好用一个已解决的例子吗？

我试图了解我的 Haswell 芯片上的 uop-cache（intel 文档中的 DSB）的行为。我以英特尔优化手册和 Agner pdf 为基础。

我发现了一组案例，其中前端可靠地回退到 MITE 解码器，这取决于代码中的微小变化，这让我感到困惑。

一个例子看起来像这样（在 gnu as 中-msyntax=intel）：

显然，这是一个荒谬的例子。我通常将它作为包含足够其他 32 字节块以溢出 LSD 以使事情更简单的循环的一部分包含在内，但这不是 AFAICT 所必需的。出于类似的原因，我将此块设置为正好 32 个字节，以排除与悬空指令相关的任何内容。

我使用两个相应的性能计数器（IDQ.MITE_UOPS 和 IDQ.DSB_UOPS）来测量 DSB 与 MITE 的使用情况。

在写入时，此 32 字节块将缓存在 DSB 中，但是将其中一个标记更改or ecx, ecx为 anadd ecx, ecx足以触发传统解码器。

这让我感到惊讶，因为两条指令具有相同的大小并且都生成 1 uop。

事实上，在玩类似的例子时，我发现在触发或不触发不同缓存行为的指令之间的唯一共同点是它们是否会与分支进行宏融合（如果有的话）。

我在任何地方都找不到此（或任何相关）行为的描述，是否有我遗漏的东西？

英特尔推送微码更新以修复名为“跳转条件代码 (JCC) 勘误表”的错误。由于在某些情况下禁用将代码放入 ICache，更新微码导致某些操作效率低下。

已发布的名为Mitigations for Jump Conditional Code Erratum 的文档不仅列出了JCC，它还列出了：无条件跳转、条件跳转、宏融合条件跳转、调用和返回。

MSVC 开关/QIntel-jcc-erratum文档提到：

在 /QIntel-jcc-erratum 下，编译器检测跨越或结束于 32 字节边界的跳转和宏融合跳转指令。

问题是：

• 是否有理由将 JCC 与其他跳跃分开处理？
• 是否有理由将提到的宏融合 JCC 与其他 JCC 分开处理？

想象一下，我们有一条指令，它被分成了 3 个微操作，并且我们有一个乱序处理器。我的问题是：这 3 个微指令必须按顺序执行，还是处理器可以将这些微指令与其他指令中的其他微指令交替执行？

我的意思是，在 OoO 处理器中，您可以乱序执行指令，但是如果我们将一条指令划分为一些微操作，这些微操作是否可以非顺序执行？

例如，我们有 3 条指令：A、B 和 C。A 和 C 已被分成 1 个微指令：A1 和 C1，而 B 已被分成 3 个微指令：B1、B2、B3。OoO 处理器能否执行，例如，B1 - A1 - B2 - C1 - B3？还是必须连续执行 B1-B2-B3？

我在这里查看 Agner Fog 的说明表，特别是在查看沙桥案例时，有一件事引起了我的注意。如果您查看 DIV 指令，您可以看到，例如，r64 DIV 指令最多可以解码 56 微指令！我的问题是：这是真的还是我误解了？

这是我什至没有想到的事情。我一直认为 2 个寄存器的整数除法仅在 1 uop 中解码。并认为该 uop 已发送到端口 0（例如在 Sandy Bridge）。

我认为这里发生的事情是：uop 被分派到 Port0 并在一些周期后完成。但是，由于流水线，每个周期可以将 1 个 div uop（或另一个需要 port0 的 uop）发送到该端口。但这完全打破了我的计划：需要在 56 个不同的周期中调度 56 个不同的微指令并占用 56 个 ROB 条目以仅执行 1 个整数除法？

Linux 定义了一个汇编器宏以BX在支持它的 CPU 上使用，这让我怀疑存在一些性能原因。

这个答案和Cortex-A7 MPCore 技术参考手册也指出它有助于分支预测。

然而，我的基准测试工作未能找到与 ARM1176、Cortex-A17、Cortex-A72 和 Neoverse-N1 CPU 的性能差异。

因此，除了与 Thumb 代码交互之外，是否有任何理由更喜欢使用 MMU 并实现 32 位 ARM 指令集的 CPU BX？MOV pc,

编辑添加基准代码，全部对齐到 64 字节：

使用执行无用的计算lr并返回BX：

在另一个寄存器上执行无用的计算并使用返回BX：

使用执行无用的计算lr并返回MOV：

使用经典函数指针序列调用：

调用使用BLX：

删除nops 会更慢。

结果为每 100000000 次循环的秒数：

我测试的 3 个 ARMv7 处理器似乎同时识别mov pc, lr和bx lr作为返回指令。然而，带有 ARM1176 的 Raspberry Pi 1被记录为具有仅识别BX lr和一些负载作为返回指令的返回预测，但我没有发现返回预测的证据。

Cortex-A17 上的结果符合预期：

然而，在我的带有 ARM1176 的 Raspberry Pi1 上，运行来自 Raspbery Pi OS 的 Linux 5.4.51+ 并没有显示出可预测指令的优势：

我们知道，直接映射缓存在缓存命中时间方面优于组关联缓存，因为不涉及对特定标签的搜索。另一方面，组关联缓存通常显示出比直接映射缓存更好的命中率。

我读到现代处理器试图通过使用一种称为方式预测的技术来结合两者的优点。他们预测给定集合中最有可能发生命中的行并仅在该行中搜索。如果尝试导致未命中，请在集合的所有缓存行中使用正常的集合关联搜索。

我想了解这种方式预测是如何工作的。预测硬件/逻辑的延迟如何小于完整集的搜索延迟？

我正在阅读该线程中缓存的拆分设计与统一设计的优缺点。

根据我的理解，拆分设计的主要优点是：拆分设计使我们能够将指令缓存放置在靠近取指单元的位置，将数据高速缓存放置在靠近内存单元的位置，从而同时减少两者的延迟。主要缺点是：指令缓存和数据缓存的组合空间可能没有得到有效利用。模拟表明，总大小相同的统一缓存具有更高的命中率。

但是，对于“为什么（至少在大多数现代处理器中）L1 缓存遵循拆分设计，但 L2/L3 缓存遵循统一设计。）”这个问题我找不到直观的答案。

以前版本的英特尔® 64 和 IA-32 架构优化参考手册包含以下编码规则：

汇编/编译器编码规则 12。（M 影响，H 通用性）
所有分支目标应为 16 字节对齐。

2020 年 5 月版本没有此规则。为什么被移除？

如Linux Kernel Mailing List 中所讨论的，对齐到 16 个字节是有代价的。但这是一个长期存在的规则，ARM 对其微架构也有同样的规则。

考虑将子程序入口点和分支目标与四字（16 字节）边界对齐。

AMD针对 AMD 系列 17h 处理器的软件优化指南说：

拥有 16 字节对齐的分支目标可以获得最大的选择器吞吐量，并避免缓存行结束短操作缓存 (OC) 条目。