assembly - 现代处理器中是否始终存在 MMX 寄存器？

Question

当我查看最新处理器的图表和概述时[1]，我从未看到提及 MMX 寄存器 MM0 - MM7。但从规范来看，它们似乎仍然存在。可以依赖它们出现在所有支持 SSE 的处理器中吗？除了更旧的 FPU 堆栈之外，它们是否与其他任何堆栈冲突？它们和一般的64位的物理寄存器是一样的吗？

虽然 XMM 和 YMM 对于向量来说要好得多，但我偶尔想使用 MMX 寄存器来存储否则会溢出到堆栈的值。 Speedwise 这看起来好一点，而且有时我想避免额外的存储和负载。

[1] http://www.realworldtech.com/haswell-cpu/

Answer 1

SSE1 意味着 MMX，所以支持 x86-64 可以保证 MMX(因为 SSE2 是 x86-64 的基准)。

它们是 80 位 x87 寄存器的别名，而不是通用整数寄存器!长模式不会改变 MMX 的工作方式。

所有现代 CPU 都支持 64 位，因此在所有模式下都可以使用 MMX。即使仅嵌入 32 位 AMD Geode CPUs有 MMX(但没有 SSE)。

<小时/>

当您拥有 16x XMM 寄存器 + 16x 64 位 GP 寄存器时，MMX 很少值得使用。 存储/重新加载并不可怕，特别是如果重新加载可以使用内存源操作数。

与存储/重新加载相比，将数据移入/移出 MMX 寄存器的额外 ALU uops 通常不值得。 Reload 通常可以作为内存源操作数进行微融合，ALU 执行端口压力很容易成为问题。

如果您在禁用缓存的情况下做了一些特殊的事情，那么当然，但是如果您可以使其远离关键路径，那么通常存储转发可以使存储/重新加载变得高效。 (它确实有大约 5 个周期的延迟)。

如果您确实想要在 XMM 和 GP 寄存器之间移动数据，通常是 movd/movq 或 pinsrd/pextrd 是一个不错的选择，而不是存储/重新加载。我的意思是，外循环中 GP 或 XMM 寄存器的溢出/重新加载通常比 2x movq 或 movq2dq xmm0, mm0 更好。

事实上，在 Skylake 上，一个 movq2dq 花费 2 uops。movdq2q 也是如此。 (不过，与 GP 寄存器之间的movq 仍然只有 1 uop，与 XMM 和 GP 寄存器之间的传输具有相同的端口 0 或端口 5 限制)。

<小时/>

此外，在函数中使用 MMX 会在函数末尾(或者如果您想符合 ABI 的话，在任何函数调用之前)花费一条 emms 指令。 MMX 寄存器在正常调用约定中都会被调用破坏(事实上，FPU 必须处于 x87 状态而不是 MMX 状态)。

<小时/>

在现代 CPU 上，MMX 绝对不如 XMM 高效。实际上，将其用于存储以外的任何用途通常比 SSE2 更糟糕(如果您想在 64 中工作，则使用 movq 加载/存储并忽略 XMM 寄存器的高字节)位 block )。

例如，在具有 movaps xmm,xmm 的 mov-elimination 的 Intel/AMD CPU 上，使用 movq xmm1, xmm0 进行 MMX 寄存器复制仍然需要 ALU uop，并且仍有 1 个周期的延迟。 (两者仍然需要前端花费一个 uop；mov-elimination 仅消除 ROB 条目之外的延迟和后端成本。)

此外，Skylake 对于某些指令的 XMM 版本的吞吐量比 MMX 版本更好。例如paddb/w/d/q mm,mm 在 p05 上运行，但 paddb/w/d/q xmm,xmm 在 p015 上运行。许多其他操作(例如 pavg*、pmadd* 和移位)可以在 XMM 寄存器的 p01 上运行，但对于 MMX 寄存器只能在端口 0 上运行。 (https://agner.org/optimize/)

与 x87 FPU 一样，它仍然支持旧代码，但支持它的执行单元较少。这还不算太糟糕，所以像 x264 和 FFmpeg 这样的软件仍然拥有大量 MMX 代码，这些代码可以自然地在 64 位 block 中工作，因此不会受到太严重的影响。

在许多情况下，128 位 AVX 版本的整数指令可能是避免寄存器复制 mov 指令的最佳选择。