Conversion of a negative float to an unsigned integer Expected flag

19 views
Skip to first unread message

sachin miglani

unread,
Mar 23, 2021, 12:55:44 AMMar 23
to RISC-V HW Dev, soura...@nxp.com, prana...@nxp.com, jeff....@nxp.com

Hi,

 

I have confusion regarding Expected flag for FCVT.WU.S Instruction when input is given -ve floating point number.

 

Section 11.7 of RISC-V Spec Says “FCVT.WU.S, FCVT.LU.S, FCVT.S.WU, and

FCVT.S.LU variants convert to or from unsigned integer values. If the rounded result is not representable in the destination format, it

is clipped to the nearest value and the invalid flag is set. Table 11.4 gives the range of valid inputs

for FCVT.int.S and the behavior for invalid inputs”

 

 Capture.JPG

All floating-point conversion instructions raise the Inexact exception if the result differs from its

operand value, yet is representable in the destination format.

 

 

Section 5.8 of IEEE 754 Spec Says “ When a NaN or infinite operand cannot be represented in the destination format and this cannot otherwise

be indicated, the invalid operation exception shall be signaled. When a numeric operand would convert to

an integer outside the range of the destination format, the invalid operation exception shall be signaled if

this situation cannot otherwise be indicated.

When the value of the conversion operation’s result differs from its operand value, yet is representable in

the destination format, some conversion operations are specified below to signal the inexact exception and

others to not signal the inexact exception.”

X27 =86400700(-3.611632924504552e-35 D)

fcvt.wu.s          x16,x27,rne


As per table, fcvt.wu.s minimum input valid =0 and 86400700 is not valid input. So o/p is is 0. But for FCSR flag, what should be result flag. 




Regards

Sachin


Andrew Waterman

unread,
Mar 23, 2021, 1:08:41 AMMar 23
to sachin miglani, RISC-V HW Dev, jeff....@nxp.com, prana...@nxp.com, soura...@nxp.com
IIRC, since the rounded result is 0, the invalid flag shouldn’t be raised (but the inexact flag should be raised). In general, you can just run your test cases through Spike to see what it does; it’s known to be correct in this respect.

--


You received this message because you are subscribed to the Google Groups "RISC-V HW Dev" group.


To unsubscribe from this group and stop receiving emails from it, send an email to hw-dev+un...@groups.riscv.org.


To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/hw-dev/8cedd92f-41fb-4f01-90ab-148ad96f95edn%40groups.riscv.org.


Nick Knight

unread,
Mar 23, 2021, 1:52:31 AMMar 23
to Andrew Waterman, sachin miglani, RISC-V HW Dev, jeff....@nxp.com, prana...@nxp.com, soura...@nxp.com
I agree with Andrew: in this case, NV shouldn't be raised, and NX should be raised. This matches IEEE-754 behavior.

As per table, fcvt.wu.s minimum input valid =0 and 86400700 is not valid input.  

The table says the minimum valid input, after rounding, is zero. (Here, "rounding" means "rounding to integer via frm".) In RNE, RTZ, RUP, and RMM --- but not RDN --- the binary32 value 0x86400700 rounds to zero.

Best,
Nick


sachin miglani

unread,
Mar 23, 2021, 2:07:29 AMMar 23
to Nick Knight, Andrew Waterman, RISC-V HW Dev, jeff....@nxp.com, prana...@nxp.com, soura...@nxp.com
Hi Nick, Andrew

Thanks for clarifying. Follow up question I have is when we have RDN,
the binary32 value 0x86400700 rounds to 0xBF800000. So NV should be
raised and NX should not be raised for fcvt.wu.s?


Regards
Sachin


On Tue, Mar 23, 2021 at 11:22 AM Nick Knight <nick....@sifive.com> wrote:
>
> I agree with Andrew: in this case, NV shouldn't be raised, and NX should be raised. This matches IEEE-754 behavior.
>
>> As per table, fcvt.wu.s minimum input valid =0 and 86400700 is not valid input.
>
>
> The table says the minimum valid input, after rounding, is zero. (Here, "rounding" means "rounding to integer via frm".) In RNE, RTZ, RUP, and RMM --- but not RDN --- the binary32 value 0x86400700 rounds to zero.
>
> Best,
> Nick
>
>
> On Mon, Mar 22, 2021 at 10:08 PM Andrew Waterman <and...@sifive.com> wrote:
>>
>> IIRC, since the rounded result is 0, the invalid flag shouldn’t be raised (but the inexact flag should be raised). In general, you can just run your test cases through Spike to see what it does; it’s known to be correct in this respect.
>>
>> On Mon, Mar 22, 2021 at 9:55 PM sachin miglani <smigla...@gmail.com> wrote:
>>>
>>> Hi,
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> I have confusion regarding Expected flag for FCVT.WU.S
>>>
>>> Instruction when input is given -ve floating point number.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Section 11.7 of RISC-V Spec Says “FCVT.WU.S, FCVT.LU.S,
>>>
>>> FCVT.S.WU, and
>>>
>>>
>>>
>>>
>>>
>>> FCVT.S.LU variants convert to or from unsigned integer
>>>
>>> values. If the rounded result is not representable in the destination format,
>>>
>>> it
>>>
>>>
>>>
>>>
>>>
>>> is clipped to the nearest value and the invalid flag is set.
>>>
>>> Table 11.4 gives the range of valid inputs
>>>
>>>
>>>
>>>
>>>
>>> for FCVT.int.S and the behavior for invalid inputs”
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>

Nick Knight

unread,
Mar 23, 2021, 2:12:24 AMMar 23
to sachin miglani, Andrew Waterman, RISC-V HW Dev, jeff....@nxp.com, prana...@nxp.com, soura...@nxp.com
Assuming you're still talking about fcvt.wu.s, yes, NV should be raised, NX should not be raised, and the instruction should return 0x0 in an X register.

Best,
Nick

sachin miglani

unread,
Mar 23, 2021, 2:16:27 AMMar 23
to Nick Knight, Andrew Waterman, RISC-V HW Dev, jeff....@nxp.com, prana...@nxp.com, soura...@nxp.com
Hi Nick,

Understood now. Thanks for clarifying once again.


Regards
Sachin
Reply all
Reply to author
Forward
0 new messages