什么是偏旗档？

Question

当读取标志时，如果发生了部分标志停滞，则会发生部分标志停滞。P4从来没有部分标志档，因为它们从来不需要合并。相反，它有虚假的依赖关系。几个答案/评论混淆了术语。他们描述了一个假依赖，但称之为部分标志停滞。这是一种减速，因为只写了一些标志，但术语“部分标志停滞”是在SNB之前的英特尔硬件上，当部分标志写必须合并时发生的情况。Intel SNB系列CPU插入一个额外的uop来合并标志而不会停滞。Nehalem和早期失速~7个循环。我不确定对AMD CPU的惩罚有多大。

我觉得我还不明白什么是“局部旗帜摊位”。我怎么知道已经发生了？除了有时读取标志之外，还有什么触发事件？合并标志是什么意思？在什么情况下“写了一些标志”但不发生部分标志合并？我需要了解什么关于旗子摊档来理解它们？

Answer 1

一般说来，当使用标志的指令读取最近的标志设置指令未写入的一个或多个标志时，就会发生部分标志停滞。

因此，像inc这样只设置一些标志（它不设置cf)的指令本身不会导致部分停顿，但如果后续指令读取inc未设置的标志(cf)（没有任何设置cf标志的中间指令），则会导致停顿。这也意味着写入所有感兴趣标志的指令永远不会出现在部分停顿中，因为在执行标志读取指令时，当它们是最近的标志设置指令时，它们一定已经写入了消耗的标志。

因此，通常，静态地确定是否会发生部分标志停滞的html" target="_blank">算法是查看使用这些标志的每个指令（通常是JCC族和cmovcc以及一些特殊指令，如ADC)，然后向后查找设置任何标志的第一条指令，并检查它是否设置了消费指令读取的所有标志。如果没有，将出现部分标志停滞。

后来的架构，从Sandy Bridge开始，本身不会出现部分标志停滞，但在某些情况下仍然会受到惩罚，即通过指令在前端添加了额外的uop。与上面讨论的失速相比，这些规则略有不同，适用于范围更窄的情况。特别地，所谓的标志合并uop只有当一个标志消耗指令从多个标志中读取并且这些标志上次由不同的指令设置时才被添加。这意味着，例如，检查单个标志的指令永远不会导致发出合并uop。

从Skylake开始（可能从Broadwell开始），我没有发现任何合并UOPS的证据。相反，uop格式被扩展为最多接受3个输入，这意味着单独重命名的进位标志和重命名的SPAZO组标志都可以用作大多数指令的输入。例外情况包括cmovbe这样的指令，它有两个寄存器输入，其条件be要求同时使用C标志和一个或多个SPAZO标志。然而，大多数条件移动只使用C和SPAZO标志中的一个或另一个，并使用一个UOP。

这里有一些例子。我们讨论了“[部分标志]停滞”和“合并uop”，但如上所述，这两个中最多只有一个适用于任何给定的体系结构，因此类似“以下导致一个停滞和一个合并uop被发出”的内容应该被理解为“以下导致一个停滞[在那些具有部分标志停滞的旧体系结构上]或一个合并uop[在那些使用合并uop的新体系结构上]”。

以下示例将导致在Sandy Bridge和Ivy Bridge上发射失速和合并uop，但在Skylake上不发射：

add rbx, 5   ; sets CF, ZF, others
inc rax      ; sets ZF, but not CF
ja  label    ; reads CF and ZF

ja指令读取cf和zf，这两个代码分别是add和inc指令最后设置的，因此插入一个合并uop以统一单独设置的标志，供ja使用。在停顿的体系结构上，由于ja从cf读取而导致停顿，而该cf不是由最近的标志设置指令设置的。

add rbx, 5   ; sets CF, ZF, others
inc rax      ; sets ZF, but not CF
jc  label    ; reads CF

这会导致停顿，因为在前面的示例中，读取cf，而上一个标志设置指令（这里是inc)没有对其进行设置。在这种情况下，可以通过简单地交换inc和add的顺序来避免停顿，因为它们是独立的，然后jc将只读取最近的标志设置操作。不需要合并uop，因为读取的标志（只有cf)都来自同一个add指令。

注意：这个案例正在辩论中（见评论）--但我不能测试它，因为我没有在我的Skylake上找到任何合并操作的证据。

add rbx, 5   ; sets CF, ZF, others
inc rax      ; sets ZF, but not CF
jnz  label   ; reads ZF

这里不需要延迟或合并uop，尽管最后一条指令(inc)只设置了一些标志，因为消费的JNZ只读取inc设置的标志（子集），而不读取其他标志。因此，这种常见的循环习惯用法（通常使用dec而不是inc)本身并不会导致问题。

下面是另一个不会导致任何停顿或合并UOP的示例：

inc rax      ; sets ZF, but not CF
add rbx, 5   ; sets CF, ZF, others
ja  label    ; reads CF and ZF

这里，ja同时读取cf和zf，并且存在一个inc，它不设置zf（即，部分标志写入指令），但是没有问题，因为add位于inc之后，并写入所有相关标志。

移位指令sar、shr和shl在它们的变量和固定计数形式下的行为与上面描述的不同（通常更差），并且这在不同的体系结构中有相当大的差异。这可能是由于它们奇怪且不一致的标记处理¹。例如，在许多体系结构上，当读取计数不是1的移位指令后的任何标志时，会出现部分标志停滞。即使在最新的架构上，由于标记处理，可变移位也有3个uops的显著成本（但没有更多的“停滞”）。

我不打算在这里包括所有血淋淋的细节，但如果你想要所有的细节，我建议在Agner的microarch doc中寻找shift这个词。

一些旋转指令也有有趣的标志相关行为，在某些情况下类似于移位。