内存目标BTS如何比加载/ BTS reg，reg / store慢得多？

问题描述

通常情况下，使用内存操作数的指令可以占用内存或寄存器操作数的速度会比mov + mov->指令-> mov + mov

慢

基于Agner Fog's instruction tables中的吞吐量和延迟（在我的情况下为Skylake，p238） 我看到btr/bts指令的以下数字：

instruction,operands,uops fused domain,uops unfused domain,latency,throughput
mov          r,r       1                  1                    0-1      .25
mov          m,r       1                  2                    2        1
mov          r,m       1                  1                    2        .5
... 
bts/btr      r,r       1                  1                    N/A      .5
bts/btr      m,r       10                 10                   N/A      5

我看不出这些数字可能是正确的。即使在最坏的情况下，也没有多余的寄存器，并且您已经将一个寄存器存储在一个临时存储位置中，这样做会更快：

## hypothetical worst-case microcode that saves/restores a scratch register
mov m,r  // + 1  throughput,save a register
mov r,m  // + .5 throughput,load BTS destination operand
bts r,do bts (or btr)
mov m,store result
mov r,restore register

最坏的情况是吞吐量要比bts m,r（4

而且微代码指令具有一组自己的寄存器，因此，看来不太可能实际需要这样做。谁能解释为什么bts（或一般而言，任何指令）与使用最坏情况移动策略相比，使用内存，寄存器操作数可以具有更高的吞吐量。

（编者注：是的，微代码可以使用一些隐藏的临时寄存器。类似add [mem],reg的东西至少在逻辑上只是加载到其中一个然后存储结果。）

解决方法

您缺少的是BT，BTC，BTS和BTR不能像使用内存操作数时所描述的那样工作。您假设内存版本与寄存器版本相同，但事实并非如此。在寄存器版本中，第二个操作数的值取模64（或16或32）。对于内存版本，第二个操作数的值照原样使用。这意味着该指令访问的实际内存位置可能不是该内存操作数给定的地址，而是它后面的某个地址。

例如，忽略保存寄存器和原子性的需要，使用BTS的寄存器版本来获得BTS [rsi + rdi],rax的相同操作，您需要执行以下操作：

LEA rbx,[rsi + rdi]
MOV rcx,rax
SHR rcx,8
MOV rdx,[rbx + rcx]
BTS rdx,rax
MOV [rbx + rcx],rdx

如果您知道RAX的值小于64，或者它是一个更简单的内存操作数，则可以简化此操作。的确，您已经注意到，在这种情况下，使用较快的寄存器版本而不是较慢的存储器版本可能是一个优势，即使这意味着需要更多指令。