时间戳

首页 > 解决方案 > 用于整数 DIV 指令的 uops

assembly - 用于整数 DIV 指令的 uops

问题描述

我在这里查看 Agner Fog 的说明表，特别是在查看沙桥案例时，有一件事引起了我的注意。如果您查看 DIV 指令，您可以看到，例如，r64 DIV 指令最多可以解码 56 微指令！我的问题是：这是真的还是我误解了？

这是我什至没有想到的事情。我一直认为 2 个寄存器的整数除法仅在 1 uop 中解码。并认为该 uop 已发送到端口 0（例如在 Sandy Bridge）。

我认为这里发生的事情是：uop 被分派到 Port0 并在一些周期后完成。但是，由于流水线，每个周期可以将 1 个 div uop（或另一个需要 port0 的 uop）发送到该端口。但这完全打破了我的计划：需要在 56 个不同的周期中调度 56 个不同的微指令并占用 56 个 ROB 条目以仅执行 1 个整数除法？

标签： assemblyx86x86-64cpu-architecturemicro-architecture

解决方案

并非所有这些微指令都在端口 0 上的实际分隔单元上运行。似乎只有签名idiv的是 Skylake 上的许多微指令，div r64“只有”33 个微指令。也许有符号idiv r64是采用绝对值来使用更窄的硬件除法器单元进行扩展精度除法，就像您对软件扩展精度所做的那样？（为什么在 x86-64 GCC 上 __int128_t 比 long long 快？）

并且idiv/div r32是“仅”10 个 uops，可能只有 1 或 2 个需要端口 0 上的实际除法单元，其他端口在其他端口上执行 IDK 操作。arith.divider_active请注意，在 Skylake 配置文件结果中显示的Trial-division 代码的计数在 Windows 上运行 32 位比在 Linux 上运行 64 位快 2 倍-div r64小输入几乎不会使实际端口 0 分频器保持活动的时间超过div r32，但其他开销使得它慢得多。

FP除法实际上是单uop，因为FP除法性能在一些现实世界的算法中很重要。（特别是divpd对周围代码前端吞吐量的影响）。请参阅浮点除法与浮点乘法

另请参阅FP 和整数除法是否在 x86 CPU 上竞争相同的吞吐量资源？- Ice Lake 改进了分隔器硬件。

另请参阅评论中的讨论以消除其他误解。

有关的：

我想我已经读过现代分隔器单元通常由迭代的非完全流水线部分构建，然后是流水线的 2 个 Newton Raphson 步骤。这就是现代 CPU 上如何部分流水线除法的方式：只要当前一个可以移动到执行单元的 Newton-Raphson 流水线部分，下一个就可以开始。

推荐阅读