有 32 个浮点标量寄存器有用吗？

不，如果您要进行矢量化，那么有时您会想要使用超过 16 个 FP向量。这绝对与将向量解包为标量无关。

通常你需要大量的 regs 来展开多个累加器来隐藏 FP 延迟，因为 FP 通常比整数 SIMD 具有更高的延迟指令。（AVX2 编译的程序是否仍然可以使用支持 AVX-512 的 CPU 的 32 个寄存器？有一个关于此的部分。）

和/或为类似exp或log在有限范围内的函数保存多项式近似的一组系数。同样，FP SIMD 比整数 SIMD 更有可能用于大量寄存器；例如，整数代码可能需要一些 AND 掩码和 shuffle-control 常量，但通常不像 FP 那么多。对于几个多项式，每个多项式都有 5 个系数的 FP 代码并不罕见，您将这些多项式除以向量化log()函数。如果您将其内联到一个循环中，以便这些常量可以保留在 regs 中，那么当您有一些用于加载和存储数据的临时 regs 时，您很容易超过 16 个寄存器，特别是如果您正在计算包括 log()但也包括其他东西的东西。

我对是否有任何体系结构使用相同的寄存器空间进行标量整数和浮点运算？也使得一些这样提，但它绝对不是重复。（该问题的主旨与此不同：GP-integer 与 SIMD（包括标量 FP）共享相同的寄存器空间，而不是将标量 FP 与向量 FP 分开。）

还是您仍然需要 32 个浮点标量寄存器，即使您还有一组向量寄存器？

呃...普通 ISA 在它们用于 SIMD 向量的相同寄存器中进行标量数学运算。所以这个问题很少出现。

我倾向于说不，除非您不能将向量寄存器用于标量 FP，或者您的向量寄存器要少得多。32 个架构寄存器通常就足够了，尤其是将寄存器重命名为更大的物理寄存器文件以隐藏迭代之间的延迟，以便独立使用相同的架构寄存器。拥有更多的状态来保存/恢复使得上下文切换更加昂贵，而使用这些标量寄存器而不是向量寄存器的另一组操作码也将是机会成本（带走可能允许未来扩展的操作码编码空间）。

32 位 ARM（带有 NEON）进行了一个有趣的权衡：d0..d31（64 位双精度 FP 寄存器）可用于 64 位 SIMD 或标量 FP，并与 16x 别名（共享空间） 128 位q寄存器。（NEON registers）不幸的是，访问寄存器的两d半q对于寄存器重命名是不方便的，就像 x86 的部分寄存器问题。（我通过没有提到 32x 32 位sregs 来简化，它别名低 16 dregs，可用于标量单精度。）

AArch64 将其简化为 32x 128 位q寄存器，每个寄存器的低半d部分是相同数字的reg（而不是 2n 和 2n+1）。q在 AArch64 中，没有寄存器名称作为reg的上半部分的别名。

对于 x86，AVX512 扩展扩展到 32 个向量寄存器（从带有 SSE2 或 AVX 的 x86-64 中的 16 个）并将它们扩展到 512 位。AVX-512 最初是为类似 GPU 的有序处理器 ( Larrabee ¹ ) 设计的，因此用于隐藏延迟的软件流水线至关重要，因为寄存器重命名无济于事。如果不是那个初始目标，IDK 会考虑英特尔是否会添加更多寄存器。如果全部都在使用中（并且不知道为零，这可能会让xsaveopt指令优化保存），它确实相当于在上下文切换时保存/恢复大量的架构状态。

脚注 1：Larrabee 最终演变成 Xeon Phi 计算卡。