repz ret：为什么这么麻烦？

Question

repz ret 的问题已在此处 [1] 以及其他来源 [2, 3] 非常令人满意地进行了介绍。然而，没有阅读这些资料，我找到了以下问题的答案：

1. 在与ret 或nop; ret 的定量比较中，实际惩罚是多少？尤其是在后一种情况下——当大多数函数要么有 100 多个或者被内联时，解码一个额外的指令（以及一个空的指令！）真的相关吗？

2. 为什么这个问题在 AMD K8 中从未得到修复，甚至进入了 K10？既然什么时候基于一个保持未记录的行为记录一个丑陋的解决方法，而不是实际解决问题，当原因的每个细节都知道的时候？

Answer 1

分支错误预测
所有喧嚣的原因是分支错误预测的成本。
当分支出现时，CPU 会预测所采用的分支并将这些指令预加载到管道中。
如果预测错误，则需要清除管道并加载新指令。
这可能需要多达number_of_stages_in_pipeline 个周期加上从缓存加载数据所需的任何周期。每次错误预测通常需要 14 到 25 个周期。

原因：处理器设计
K8 和 K10 之所以会出现这种情况，是因为 AMD 进行了一次漂亮的优化。
AMD K8 和 K10 将预解码缓存中的指令并跟踪它们在 CPU L1 指令缓存中的长度。
为了做到这一点，它有额外的位。

For every 128 bits (16 bytes) of instructions there are 76 bits of additional data stored。

下表详细说明了这一点：

Data             Size       Notes
-------------------------------------------------------------------------
Instructions     128 bits   The data as read from memory
Parity bits      8 bits     One parity bit for every 16 bits
Pre-decode       56 bits    3 bits per byte (start, end, function) 
                            + 4 bit per 16 byte line
Branch selectors 16 bits    2 bits for each 2 bytes of instruction code

Total            204 bits   128 instructions, 76 metadata

由于所有这些数据都存储在 L1 指令缓存中，K8/10 cpu 在解码和分支预测上的工作量要少得多。这样可以节省硅。
而且由于 AMD 没有像英特尔那样大的晶体管预算，它需要更智能地工作。

但是，如果代码是 esp。紧一个跳转和一个 ret 可能占用相同的两个字节槽，这意味着 RET 被预测为未使用（因为它后面的跳转是）。
通过使 RET 占用两个字节 REP RET 这永远不会发生，并且 RET 将始终被预测为 OK。

英特尔没有这个问题，但（过去）遭受预测插槽数量有限的问题，而 AMD 则没有。

nop ret
从来没有理由做nop ret。这是两条指令浪费了一个额外的周期来执行 nop 和 ret 可能仍然与跳转“配对”。
如果要对齐，请改用REP MOV 或使用multibyte nop。

结束语
只有本地分支预测与指令一起存储在缓存中。
还有一个单独的全局分支预测表。