Conversion of a negative float to an unsigned integer Expected flag

[sachin miglani]

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”

 

 

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]

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]

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

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/hw-dev/CA%2B%2B6G0AVPZYWt%2B%2BbnCmGMEVkdP1UwZwQqBSAHx%2BHniby0wjTqg%40mail.gmail.com.

[sachin miglani]

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]

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]

Hi Nick,

Understood now. Thanks for clarifying once again.


Regards
Sachin