到分段寄存器的mov比到通用寄存器的mov慢吗？

Question

具体是：

mov %eax, %ds

mov %eax, %ebx

注意，我关心的是旧的x86 linux CPU，而不是现代的x86_64 CPU，那里的分段工作方式不同。

Answer 1

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

在Ivybridge和以后的版本中，它甚至不需要执行单元，并且具有零延迟。它在寄存器重命名阶段处理。x86的MOV真的能“免费”吗？为什么我根本不能复制这个？即使在早期的CPU上，任何ALU端口都是1 uop（因此通常每个时钟吞吐量为3或4 uop）。

在AMD Piledriver/SteamRolly，MOV r32、r32和r64上，r64可以在AGU端口和ALU端口上运行，使其每时钟吞吐量为4个，而add或MOV在8位或16位寄存器（必须合并到目的地）上每时钟吞吐量为2个。

null

其他CPU类似：

>

ppro/pii/piii（原始P6):p0的8个uops，没有列出吞吐量。5周期潜伏期。（请记住，这个uarch是在1995年发布之前设计的，当时16位代码仍然很常见。这就是为什么P6-family对整数寄存器（AL,AH与AX分开）进行部分寄存器重命名）

Pentium4:4个uops+4个微码，14C吞吐量。

延迟=12C 16位实值或vm86模式，24C 32位保护模式。12c是他在主表中列出的，所以他对其他CPU的延迟数可能也是实模式延迟，其中编写段reg只设置base=sreg<<4。）

Skylake（我的测试用循环外读取的值重新加载它们）：在一个只有dec/jnz的循环中：10个融合域UOP（前端），6个未融合域（执行单元）。每18C吞吐量一个。

在一个循环中，对4个不同的seg regs（DS/ES/FS/Gs）都使用相同的选择器：每25C吞吐量4个MOV，6个融合/未融合域UOP。（也许有些被取消了？）

在一个循环中，向ds4次写入：每72C一个iter（每18C一个MOV ds、EAX)。相同的uop计数：每mov有6个融合和未融合。

>

K7/K8/K10:6“OPS”,8C吞吐量。

Atom:7 uops，21C吞吐量

有序奔腾(P5/PMMX)有更便宜的MOV-to-SR：Agner将其列为“>=2个循环”，且不可配对。(P5是有序的2宽超标量，有一些配对规则，指令可以在这些规则上一起执行）。对于保护模式来说，这似乎很便宜，所以也许2是在真实模式下，保护模式是大于？我们从他的P4表笔记中知道，他当时在16位模式下测试东西。

他说Sandybridge“可能”可以重命名segment regs，Haswell/Broadwell/Skylake“可能”可以重命名它们。我在SKL上的快速测试表明，重复编写相同的段reg比编写不同的段reg慢，这表明它们没有完全重命名。放弃支持似乎是一件显而易见的事情，因为它们很少在普通的32/64位代码中被修改。

而且每个seg reg通常一次只修改一次，因此对于同一段寄存器来说，多个dep链并不是很有用。（也就是说，在Linux中，对于段regs，您不会看到WAW的危险，而且WAR也几乎不相关，因为内核不会使用用户空间的DS来引用内核入口点中的任何内存。（我认为中断是序列化的，但是通过syscall进入内核可能仍然会有用户空间加载或存储，但还没有执行。）

在第2章中，它解释了一般的无序执行（除了P1/PMMX之外的所有CPU），2.2寄存器重命名说“可能会重命名段寄存器”，但IDK如果他的意思是一些CPU可以重命名而一些不可以重命名，或者如果他不确定一些旧的CPU。他没有在PII/PII或Pentium-M部分提到seg reg的重命名，所以我不能告诉你你显然在问的旧的32位专用CPU。（他在K8之前没有AMD的微弓引导部分。）

FS和GS在长模式下的工作与在保护模式下的工作基本相同，这是其他seg regs在长模式下被“绝育”。我认为Agner Fog的Core2/Nehalem数字可能与保护模式下的PIII类似。它们是同一个微架构家族的一部分。我不认为我们有一个有用的数字P5奔腾段寄存器写在保护模式。

（Sandybridge是从P6-family派生出来的一个新家族中的第一个，其内部发生了重大变化，P4的一些想法实现了一种不同（更好）的方式，例如，SnB的decoded-uop缓存不是跟踪缓存。但更重要的是，SnB使用物理寄存器文件，而不是将值正确地保存在ROB中，因此它的寄存器重命名机制是不同的。）