Negative zero

73 views
Skip to first unread message

Anoop Mysore

unread,
Apr 7, 2023, 3:55:01 PM4/7/23
to RISC-V ISA Dev
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

unread,
Apr 7, 2023, 4:03:27 PM4/7/23
to RISC-V ISA Dev, Anoop Mysore
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

unread,
Apr 7, 2023, 4:38:21 PM4/7/23
to RISC-V ISA Dev, Craig Topper, Anoop Mysore
I see, thank you! Are there any RISC-V specific differences with anything on the Wikipedia page?

Bruce Hoult

unread,
Apr 8, 2023, 8:33:32 AM4/8/23
to Anoop Mysore, RISC-V ISA Dev, Craig Topper
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

unread,
Apr 8, 2023, 3:16:02 PM4/8/23
to RISC-V ISA Dev, Bruce Hoult, RISC-V ISA Dev, Craig Topper, Anoop Mysore
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

unread,
Apr 8, 2023, 6:03:12 PM4/8/23
to MitchAlsup, RISC-V ISA Dev, Craig Topper, Anoop Mysore
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.

MitchAlsup

unread,
Apr 8, 2023, 6:10:24 PM4/8/23
to RISC-V ISA Dev, Bruce Hoult, RISC-V ISA Dev, Craig Topper, Anoop Mysore, 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

unread,
Apr 23, 2023, 11:40:29 AM4/23/23
to RISC-V ISA Dev, MitchAlsup, Bruce Hoult, RISC-V ISA Dev, Craig Topper, 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

unread,
Apr 23, 2023, 7:58:40 PM4/23/23
to Anoop Mysore, RISC-V ISA Dev, MitchAlsup, Bruce Hoult, Craig Topper
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.

Anoop Mysore

unread,
Apr 23, 2023, 8:18:13 PM4/23/23
to Nick Knight, RISC-V ISA Dev, MitchAlsup, Bruce Hoult, Craig Topper
Oh I see, that totally makes sense now, thank you so much for your help!

Nick Knight

unread,
Apr 23, 2023, 8:33:16 PM4/23/23
to Anoop Mysore, RISC-V ISA Dev, MitchAlsup, Bruce Hoult, Craig Topper
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

unread,
Apr 24, 2023, 11:35:04 AM4/24/23
to Anoop Mysore, Nick Knight, RISC-V ISA Dev, MitchAlsup, Bruce Hoult, Craig Topper
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


Reply all
Reply to author
Forward
0 new messages