Negative zero

[Anoop Mysore]

From reading the wikipedia page, I understand the basic arithmetic with signed zero (Wiki: https://en.wikipedia.org/wiki/Signed_zero). However, there are certain cases not explicitly covered in the examples there. For example, what would be the value of (-0) + (+0) -- I can see that as both small values on either side of zero -- which doesn't help pinpoint an answer. Or do we take the sign of the leading operand (-) for the result?

[Craig Topper]

This is covered by "x - x = x + (-x) = +0 (for any finite x, -0 when rounding toward negative)". The "for any finite x" includes 0. The result is -0 for RDN rounding mode and +0 for other rounding modes.

[Anoop Mysore]

I see, thank you! Are there any RISC-V specific differences with anything on the Wikipedia page?

[Bruce Hoult]

RISC-V follows IEEE-754-2008. If anything is different that would be a bug.

--
You received this message because you are subscribed to the Google Groups "RISC-V ISA Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isa-dev+u...@groups.riscv.org.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/eb7a766f-16d4-47c6-a056-f77c853a0c1cn%40groups.riscv.org.

[MitchAlsup]

On Saturday, April 8, 2023 at 7:33:32 AM UTC-5 Bruce Hoult wrote:

RISC-V follows IEEE-754-2008. If anything is different that would be a bug.

There is a IEEE 754-2019.

The major difference is that in -2008

fmax( x, NaN ) = x

fmin( x, NaN ) = x

while in -2019

fmax( x, NaN ) = NaN

fmin( x, NaN ) = NaN

2019 is a bit more sane than -2008, especially in that regard. 

[Bruce Hoult]

Isn't that reverting to the 1985 spec for max and min?

--

You received this message because you are subscribed to the Google Groups "RISC-V ISA Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isa-dev+u...@groups.riscv.org.

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/3d9dfb9d-993c-4369-841b-415d03720ba5n%40groups.riscv.org.

[MitchAlsup]

Apparently using a NaN to represent an empty cell in a spreadsheet did not work out so well.....

On Saturday, April 8, 2023 at 5:03:12 PM UTC-5 Bruce Hoult wrote:

Isn't that reverting to the 1985 spec for max and min?

--

[Anoop Mysore]

Thanks for the clarification!
I'm running a test in assembly to check out a few cases. Specifically, I'm trying the following: (highlight for brevity)
800001dc: 0010071b addiw a4,zero,1 800001e0: 01f71713 slli a4,a4,0x1f // a4 = 0x8000_0000 (-0 when interpreted as fp32) 800001e4: 123457b7 lui a5,0x12345 800001e8: 6787879b addiw a5,a5,1656 // a5 = 0x1234_5678 (some positive num) 800001ec: f0070753 fmv.w.x fa4,a4 // (single precision) move them both to FP regs 800001f0: f00787d3 fmv.w.x fa5,a5 800001fc: 12f77853 fmul.d fa6,fa4,fa5 // (double precision) mul them 80000200: 12e7f8d3 fmul.d fa7,fa5,fa4 Q1. Is the above assembly a valid code? Specifically, would PC=800001fc be a valid instruction to run? It's computing fmul.d on single precision values.
Q2. The expected result in fa6 is 0x8000_0000_0000_0000, (-0.0 in decimal) right? (Because Dromajo computes it to be 0x7ff8_0000_0000_0000 (NaN in decimal), I'm not sure who's right)

[Nick Knight]

The assembly code is valid, in the sense that the instructions are legal. At least they appear to be, I'm just skimming quickly. Please see Section 14.2 of the ISA spec to understand why NaN --- indeed, the canonical (q)NaN --- is the expected result.

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/ad5e001f-6f48-4b31-bdf6-4bc7d47b8c66n%40groups.riscv.org.

[Anoop Mysore]

Oh I see, that totally makes sense now, thank you so much for your help!

[Nick Knight]

No problem.

You might notice that IEEE-754, Clause 6.2.3 says,

If two or more inputs are NaN, then the payload of the resulting NaN should be identical to the payload of
one of the input NaNs if representable in the destination format. This standard does not specify which of
the input NaNs will provide the payload.

However, fmul.d is clearly not propagating either payload.

But note that IEEE-754 says "should", not "shall", so this is just a recommendation, one that the standard RISC-V floating-point extensions do not follow. (On the other hand, fflags.NV shall be asserted here, since an input operand is a sNaN.)

[Tommy Thorn]

Thanks for mentioning Dromajo.  It’s been extensively verified (and the very many bug fixes is one of the major differences from the original RISCVEMU/TinyEMU).  However, if you do find bugs, the please file an issue on github.

Thanks,

Tommy — principal maintainer of Dromajo

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/CAPPvrXdkTONkYXzV1eX-cqPCDP%3DVmB90LcE3B5e1SPZQJQYNhQ%40mail.gmail.com.