Arm架构中FABS、FMAX*等指令不返回默认NaN的原理与障碍咨询

一、原理说明 #

这些指令的设计逻辑和DN位的定位存在本质差异，具体原因如下：

• 指令语义的核心目标：FABS、FNEG是对浮点操作数进行符号位修改的位级操作，FMAX*/FMIN*是对两个操作数进行数值选择的指令，它们的核心是保留操作数的有效属性，而非生成新的计算结果。当输入是NaN时，用户使用这些指令的预期是修改NaN的符号，或是从操作数中选择有效数值，而非替换成无意义的默认NaN。
• IEEE 754标准的约束：这类指令的行为被IEEE 754浮点标准明确规定：
  • FABS/FNEG需保留NaN的编码结构，仅修改符号位；
  • FMAX*/FMIN*在存在非NaN操作数时必须返回非NaN值，仅当两个操作数均为NaN时才返回NaN（且为原始NaN）。
• DN位的设计定位：DN位是为会产生新NaN的复杂浮点运算（如0/0、负数开平方）或运算中NaN导致结果不确定的场景设计的，目的是统一返回默认NaN来简化异常处理；而上述指令不会生成新NaN，只是传递或选择已有操作数，因此不在DN位的作用范围内。

二、实现这些指令返回默认NaN的障碍 #

• 违反标准兼容性：强制返回默认NaN会直接违背IEEE 754标准的规定，导致硬件无法兼容依赖标准浮点行为的软件，破坏生态兼容性。
• 违背指令语义：这些指令的核心用途是符号修改或数值选择，返回默认NaN会完全偏离用户的使用意图——例如用户调用FABS处理一个负NaN，预期得到正NaN，而非与输入无关的默认值。
• 硬件实现成本提升：要支持该行为，需要在这些指令的执行路径中额外添加DN位判断逻辑、默认NaN生成电路，会增加硬件面积和执行延迟，而这类指令原本被设计为轻量快速执行的操作。
• 软件适配风险：现有大量科学计算库、数值处理软件依赖这些指令的标准行为，修改后会导致这类软件出现不可预测的错误、计算结果失真甚至崩溃。

内容的提问来源于stack exchange，提问作者pmor