qemu-riscv
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v3 2/2] target/riscv: change the api for single/double fmin/f


From: Alistair Francis
Subject: Re: [PATCH v3 2/2] target/riscv: change the api for single/double fmin/fmax
Date: Mon, 18 Oct 2021 10:18:07 +1000

On Sun, Oct 17, 2021 at 4:59 PM Frank Chang <frank.chang@sifive.com> wrote:
>
> On Sun, Oct 17, 2021 at 8:55 AM Frank Chang <frank.chang@sifive.com> wrote:
>>
>> On Sun, Oct 17, 2021 at 1:56 AM Richard Henderson 
>> <richard.henderson@linaro.org> wrote:
>>>
>>> On 10/16/21 1:52 AM, Frank Chang wrote:
>>> > On Sat, Oct 16, 2021 at 1:05 AM Richard Henderson 
>>> > <richard.henderson@linaro.org
>>> > <mailto:richard.henderson@linaro.org>> wrote:
>>> >
>>> >     On 10/14/21 11:54 PM, frank.chang@sifive.com 
>>> > <mailto:frank.chang@sifive.com> wrote:
>>> >      > From: Chih-Min Chao<chihmin.chao@sifive.com 
>>> > <mailto:chihmin.chao@sifive.com>>
>>> >      >
>>> >      > The sNaN propagation behavior has been changed since
>>> >      > cd20cee7 inhttps://github.com/riscv/riscv-isa-manual
>>> >     <http://github.com/riscv/riscv-isa-manual>
>>> >      >
>>> >      > Signed-off-by: Chih-Min Chao<chihmin.chao@sifive.com 
>>> > <mailto:chihmin.chao@sifive.com>>
>>> >      > ---
>>> >      >   target/riscv/fpu_helper.c | 8 ++++----
>>> >      >   1 file changed, 4 insertions(+), 4 deletions(-)
>>> >      >
>>> >      > diff --git a/target/riscv/fpu_helper.c b/target/riscv/fpu_helper.c
>>> >      > index 8700516a14c..1472ead2528 100644
>>> >      > --- a/target/riscv/fpu_helper.c
>>> >      > +++ b/target/riscv/fpu_helper.c
>>> >      > @@ -174,14 +174,14 @@ uint64_t helper_fmin_s(CPURISCVState *env, 
>>> > uint64_t rs1,
>>> >     uint64_t rs2)
>>> >      >   {
>>> >      >       float32 frs1 = check_nanbox_s(rs1);
>>> >      >       float32 frs2 = check_nanbox_s(rs2);
>>> >      > -    return nanbox_s(float32_minnum(frs1, frs2, &env->fp_status));
>>> >      > +    return nanbox_s(float32_minnum_noprop(frs1, frs2, 
>>> > &env->fp_status));
>>> >      >   }
>>> >
>>> >     Don't you need to conditionalize behaviour on the isa revision?
>>> >
>>> >
>>> > I will pick the right API based on CPU privilege spec version.
>>>
>>> There's a separate F-extension revision number: 2.2.
>>>
>>> But I'll leave it up to those more knowledgeable about the revision 
>>> combinations actually
>>> present in the field to decide.
>>>
>>
>> I did some history searches on RISC-V ISA spec Github repo.
>>
>> F-extension was bumped to v2.2 at (2018/08/28):
>> https://github.com/riscv/riscv-isa-manual/releases/tag/draft-20180828-eb78171
>> The privilege spec is v1.10-draft at the time.
>>
>> and later ratified at (2019/03/26):
>> https://github.com/riscv/riscv-isa-manual/releases/tag/IMFDQC-Ratification-20190305
>>
>> The spec was updated to use IEEE 754-2019 min/max functions in commit: 
>> #cd20cee7 (2019/06/05).
>
>
> Sorry, the commit date is 2017/06/05, not 2019/06/05.
>
> But I think it's probably easier and clearer to just introduce an extra 
> fext_ver variable.
> We can set CPUs which are Privilege spec v1.10 to RVF v2.0 
> (FEXT_VERSION_2_00_0),
> and others with Privilege spec v1.11 to RVF v2.2 (FEXT_VERSION_2_02_0).

I think it's probably simpler to just tie this to the priv_spec. It's
not completely accurate, but it should be close enough. Otherwise we
have the risk of having too many version variables and it becomes a
pain for users to deal with.

If the unpriv spec is better, we could also introduce that. We will
probably need that one day for something else anyway.

If you feel that we really need a fext_ver (to avoid large software
breakage for example) then it's also ok, we just need to justify why.

Alistair

>
> Any comments are welcome.
>
> Regards,
> Frank Chang
>
>>
>>
>> Privilege spec v1.11 is ratified at (2019/06/10):
>> https://github.com/riscv/riscv-isa-manual/releases/tag/Ratified-IMFDQC-and-Priv-v1.11
>>
>> In fact, Unprivileged spec v2.2 was released at (2017/05/10):
>> https://github.com/riscv/riscv-isa-manual/releases/tag/riscv-user-2.2
>>
>> and Privilege spec v1.10 was released at (2017/05/10):
>> https://github.com/riscv/riscv-isa-manual/releases/tag/riscv-priv-1.10
>>
>> Privilege spec was then bumped to v1.11-draft in the next draft release 
>> right after v1.10 (2018/05/24):
>> https://github.com/riscv/riscv-isa-manual/releases/tag/draft-20180524001518-9981ad7
>> (RVF was still v2.0 at the time.)
>>
>> It seems that when Privilege spec v1.11 was ratified, RVF had been bumped to 
>> v2.2,
>> and when Privilege spec v1.10 was ratified, RVF was still v2.0.
>>
>> As in QEMU, there's only priv_ver variable existing for now.
>> So unless we introduce other variables like: unpriv_ver or fext_ver.
>> Otherwise, I think using priv_ver is still valid here.
>> Though it is not accurate, somehow confused,
>> and may not be true anymore in future standards.
>>
>> Let me know which way is better for our maintenance.
>>
>> Thanks,
>> Frank Chang
>>
>>> r~



reply via email to

[Prev in Thread] Current Thread [Next in Thread]