NaN propagation about nyuziprocessor HOT 1 CLOSED

The RISC-V spec (v2.1, section 7.3) makes a compelling case for not supporting this:

"Except when otherwise stated, if the result of a floating-point operation is NaN, it is the canonical NaN. The canonical NaN has a positive sign and all significand bits clear except the MSB, a.k.a. the quiet bit...We considered propagating NaN payloads, as is recommended by the standard, but this decision would have increased hardware cost. Moreover, since this feature is optional in the standard, it cannot be used in portable code."

I found another more subtle problem that makes NaN propagation less useful (and hard to validate): the Clang compiler treats floating point addition as commutative and will freely reorder operands, which makes the behavior unpredictable. For example, the following code in the emulator:

        case OP_ADD_F:
            return value_as_int(value_as_float(value1) + value_as_float(value2));
        case OP_SUB_F:
            return value_as_int(value_as_float(value1) - value_as_float(value2));

Assembles to:

case OP_ADD_F:
100005663:	66 0f 6e c6 	movd	%esi, %xmm0
100005667:	66 0f 6e ca 	movd	%edx, %xmm1
10000566b:	f3 0f 58 c8 	addss	%xmm0, %xmm1
10000566f:	eb 21 	jmp	33 <_scalar_arithmetic_op+0x1A2>

case OP_SUB_F:
100005671:	66 0f 6e c6 	movd	%esi, %xmm0
100005675:	66 0f 6e ca 	movd	%edx, %xmm1
100005679:	f3 0f 5c c1 	subss	%xmm1, %xmm0

In the OP_ADD_F case, %esi is passed as the first parameter of addss, but in the OP_SUB_F case, it is passed as the second. The compiler has reordered the operands for the add case. The addss instruction on x86 uses the first operand as the result in the case where both are NaN, but the behavior of the emulator is to use the second value now because the compiler has rearranged them.

from nyuziprocessor.