问题标签 [x87]

我正在阅读Intel 说明手册，发现有一条“NOP”指令在主 CPU 上什么都不做，而一个“FNOP”指令在 FPU 上什么也不做。为什么有两个单独的指令什么都不做？

我看到的唯一不同的是它们抛出了不同的异常，因此您可能会观察 FNOP 的异常以检测是否有可用的 FPU。但是没有像 CPUID 这样的其他机制来检测这个吗？有两个单独的 NOP 指令有什么实际原因？

我注意到编译器在每次使用double算术时都会生成针对 SIMD 寄存器的代码。这适用于未优化和优化的代码。这是否意味着 x87 FP 单元可以被认为是过时的并且只是为了向后兼容而存在？

我还注意到其他“流行”平台也依赖于它们各自的 SIMD 实现，而不是设计为堆栈的 FP。

此外，SIMD 实现往往至少为 128 位宽，所以我想知道这是否意味着操作的（内部）精度高于 x87 FP 单元？

我还想知道性能、吞吐量和延迟，考虑到 SIMD 是在考虑向量执行的情况下构思的，所以我想知道它们如何处理标量。

回到 Intel 最初设计 8087 的时候，为什么他们选择将浮点寄存器组织为堆栈？从这样的设计中可以获得什么可能的优势？与允许将任意寄存器用作源操作数和目标操作数相比，它似乎更不灵活且更难使用。

我们的课程练习要求我们在 GNU 汇编中创建一个 delta = b2 - 4ac 函数，并从 C 中访问它。由于这是一门关于编译器的课程，而不是关于汇编的课程，教授选择只演示整数功能，并期望一个整数功能。

但是，我希望个人学习能够超越职责范围，并创建一个返回浮点而不是整数的可用函数。

我想出了这个 C （不要介意全局变量，下一个练习的目的是使用带有参数的适当函数）：

还有这个 GNU GAS：

谷歌让我相信我应该在浮点堆栈的顶部留下一个浮点结果，但这不起作用，并且在 C 调用程序中打印的结果总是 0.0000000。

我必须错过一个非常小的东西，但是没有多少谷歌搜索会带来它，有人能指出我正确的方向吗？感谢您的关注。

如果一种语言希望在 x87 硬件和支持 binary128 类型的硬件上提供一致的浮点语义，现有的 binary128 实现是否能够使用要求所有中间结果舍入等效于 80 位类型的规则高效运行在 x87 上找到？尽管 x87 不能有效地使用需要以等效float或double精度评估结果的语言，因为这些类型具有不同的指数范围，因此具有非规范化值的不同行为，但似乎 binary128 和 binary80 都使用相同大小的指数字段，因此，四舍五入有效的底部 48 位应该在整个类型的计算范围内产生一致的结果。

语言设计假设未来的 PC 风格硬件将通过 x87 指令或通过可以模拟 80 位类型行为的 FPU 支持 80 位类型，即使值需要 128 位来存储，这是否合理？ ?

例如，如果一种语言定义了类型：

• ieee32 == Binary32 ，除了 real32 或 realLiteral 之外，不能隐式转换为/从任何其他类型转换
• ieee64 == Binary64 ，除了 real64 或 realLiteral 之外，不能隐式转换为/从任何其他类型
• real32 == Binary32 急切地转换为 realComp 以进行所有计算，并且可以从所有实数类型隐式转换
• real64 == Binary64 急切地转换为 realComp 以进行所有计算，并且可以从所有实数类型隐式转换
• realComp == 中间结果类型，无论存储在其中的精度如何，都需要 128 位来存储
• realLiteral == 无后缀浮点字面量和常量表达式的类型；在内部作为最大精度值处理，但只能用作文字和常量表达式的类型；存储为最大精度，除非它会立即强制转换为较小的类型，在这种情况下，它将存储为目标类型。

语言是否可以提供承诺始终以 80 位精度处理的语义realComp，或者这样的承诺可能会在某些平台上造成执行时间损失？将其简单地指定为 80 位或更好，并承诺任何有时具有 128 位精度的平台都会始终如一地这样做会更好吗？应该尝试在具有完全 64 位 FPU 的硬件上承诺什么（在没有 64 位 FPU 的典型 16 位或 32 位微控制器上，计算realComp会比 on 更快double）？

I have a pair of 32-bit floats stored in eax and ecx. Can I directly load these into the FPU to operate on them, without first storing to memory? This would simplify some compiler code significantly, but fld seems to only be able to operate on memory.

使用 fldcw 指令可以将 FPU 单元的精度更改为 24 位或更多位。然而，在做了一些测试之后，我开始认为实际上很少有 x87 操作使用该设置。

我尚未测试所有操作，但到目前为止，在这台测试机器上，看起来只有 fdiv 和 fsqrt 以选定的精度停止计算，并且所有其他操作（fadd fsub fmul ...）总是计算完整的扩展精度。

如果是这种情况，我希望它是因为这 2 条指令（fdiv 和 fsqrt）比大多数其他 x87 FPU 指令慢得多，所以当较低的精度足够时，可以加快它们的速度，但实际上，我只是想知道如果一直都是这种情况，或者这是我的测试机器中使用的最新处理器的怪癖。

编辑：这是显示它的delphi代码

edit2：误报，我弄错了，我存储为单个而不是扩展，所以无法发现差异，这是一个固定的测试，感谢 hans passant 发现了我的错误：

我正在开发一个经常需要将 6 到 8 个有符号 32 位整数转换为 32 位实数的应用程序。我用自定义汇编代码替换了 delphi 代码，令我惊讶的是，FPU 转换总是一样快，并且在某些计算机上比 SSE 转换快很多。这是一些说明的代码：

在转换过程中需要重新缩放（所以是乘法），这就是为什么里面有一个。使用的值只是我选择的一个随机值，但无论我使用什么值，结果都是一样的。FPU 和 SSE 之间的舍入也有非常小的差异，但在这种情况下并不重要。

但是，如果您运行该代码，您会发现 FPU 路径永远不会比 SSE 路径慢，而且它没有任何意义。有人知道发生了什么吗？

编辑：这是汇编程序中带有循环的不同源代码。结果真的很有趣。如果注释掉增量指令，SSE 版本比 FPU 版本快很多，但如果包含增量指令，那么它们的速度大致相同：

在给定角度的理想世界中，恒等式 FSIN * FSIN + FCOS * FCOS = 1 始终成立，但由于浮点限制，它并不完全正确。例如，将一个小值（如单个 0x2F800001）传递给 FCOS 将给出 1 的结果，而 FSIN 将给出大于零的结果，因此在这种情况下 FSIN * FSIN + FCOS * FCOS > 1 。

在我正在处理的当前应用程序中，这是不可接受的，但如果 FSIN * FSIN + FCOS * FCOS <= 1 是可以接受的。可悲的是，即使在向零 FPU 舍入模式下，上述结果仍然会发生，所以我需要对此做点什么。

我只是想知道是否有人有一个比重新定义 FSIN 或 FCOS 更快的解决方案，因为该解决方案的性能相当低： FSIN = sqrt(1- FCOS * FCOS ) 。

我宁愿不使用任何外部库来让客户满意，所以想要一个汇编程序或 delphi 的解决方案（客户使用 delphi 2009）。

编辑：

这与我描述的想要发生的完全一样，FSIN * FSIN + FCOS * FCOS <= 1 对于所有有效角度，舍入标志设置为 trunc。因此，当我明天回去工作时，我将不得不跟踪以找到客户端的编译器在哪里重置舍入模式，或者制作一个汇编版本的计算。

我是 masm 的新手，我不知道如何管理浮点数。我试图在 masm Assembly 中找到指数值 e^x。其中 x 是浮点数。例如 e^2.3