Assembly mov到分段寄存器的速度是否比mov到通用寄存器的速度慢？

具体是：

mov %eax, %ds

慢于

mov %eax, %ebx

或者它们的速度相同。我在网上进行了研究，但一直无法找到确切的答案

我不确定这是否是一个愚蠢的问题，但我认为修改分段寄存器可以让处理器做额外的工作

---

注意：我关心的是旧的x86 linux CPU，而不是现代的x86_64 CPU，因为它们的分段工作方式不同。

mov%eax，%ebx

在通用寄存器之间是最常见的指令之一。现代硬件非常有效地支持它，通常在特殊情况下不适用于任何其他指令。在旧的硬件上，它一直是最便宜的指令之一

在Ivybridge和更高版本上，它甚至不需要执行单元，并且没有延迟。它在注册重命名阶段处理。即使在早期的CPU上，任何ALU端口的吞吐量都是1 uop（因此通常每个时钟的吞吐量是3或4）

在AMD Piledriver/Steamroller上，

mov r32、r32

和r64，r64可以在AGU端口和ALU端口上运行，使其每时钟吞吐量为4，而add为每时钟吞吐量为2，或者在8位或16位寄存器（必须合并到目标中）上运行

mov

---

在典型的32位和64位代码中，段reg的mov指令是相当罕见的指令。不过，这是内核对每个系统调用（可能是中断）所做的工作的一部分，因此提高它的效率将加快系统调用和I/O密集型工作负载的快速路径。因此，即使它只出现在少数几个地方，它也可以运行相当数量。但是它与mov r，r相比仍然是次要的

mov

到段寄存器的速度很慢：它触发来自GDT或LDT的加载以更新描述符缓存，因此它是微码的

即使在x86-64长模式下也是如此；中的段基本/限制字段被忽略，但它仍然必须使用中的其他字段更新描述符缓存，包括应用于数据段的DPL（描述符特权级别）

---

列出Nehalem和早期CPU的

mov sr，r

（英特尔synax，mov到段reg）的uop计数和吞吐量。他停止了为后来的CPU测试seg REG，因为它很模糊，编译器（或人工优化）也不使用它，但SnB家族的计数可能有些相似。（也不测试seg REG，例如，不在此测试中）

Nehalem上的MOV sr，r（可能在保护模式或长模式下测试）：

• 前端的6个熔合域UOP
• ALU端口的3个UOP（p015）
• 装货港的3个UOP（p2）
• 吞吐量：每13个周期1次（用于在一个大循环中重复此指令数千次）。IDK，如果CPU重命名段注册表。否则，它可能会暂停以后的加载（或所有以后的指令？），直到描述符缓存被更新并且mov to sr指令失效。i、 我不确定这会对周围代码的无序执行产生多大影响

其他CPU类似：

• PPro/PII/PIII（原始P6）：p0为8 UOP，未列出吞吐量。5周潜伏期。（请记住，这个uarch是在1995年发布之前设计的，当时16位代码仍然很常见。这就是为什么P6系列对整数寄存器进行部分寄存器重命名（AL，AH与AX分开））
• 奔腾4:4 uops+4微码，14c吞吐量

  ---

  延迟=12c 16位实数或vm86模式，24c处于32位保护模式。12c是他在主表中列出的，因此他对其他CPU的延迟数也可能是实模式延迟，其中写入段reg只是将base=

  sreg添加到Peter所说的内容中，在使用Sandy Bridge及以后的PRF方案时，寄存器之间的移动只是将指定体系结构寄存器的RAT指针更改为源体系结构寄存器的情况，因此没有执行单元
  
  从微序列器到段寄存器的移动约为8 uops。它在nehalem上也有14个循环的反向吞吐量，这意味着发生了管道刷新，它可能作为微码辅助运行。微码例程包含描述符到专用描述符寄存器的内存负载，作为RS（保留站）中的目标
  
  移动到段寄存器可以通过重命名机制处理。段寄存器可以与描述符一起重命名，然后从逻辑地址加载导致描述符作为源和偏移寄存器复制到保留站，并由带有AGU的执行端口处理。这可能是浪费，因为RS必须为每个条目都有一个描述符字段，其中DS段将被读取并复制到RS中，每个条目都是相同的。英特尔的专利也在讨论这一点。有人建议RS还可以为段寄存器源或目的地以及描述符源或目的地设置单独的条目
  
  或者，移动到段寄存器可以简单地刷新和序列化管道，确保无序内核中的所有内存操作使用正确的段描述符。在远端调用中更改CS段时必须发生这种情况，因为解码阶段取决于描述符字段的内存和操作数大小。对于mov，AGU可以根据操作码字段中的段重写直接从段描述符读取，而不必从RS读取重命名的描述符。远跳转实际上可以由MSROM在线完成，而不是退出，因为远跳转不会进行预测，而且总是不进行预测失误，其效果是解码器具有更新的CS，因为CS和CS描述符写入在