From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B0F0EC433EF for ; Mon, 18 Oct 2021 04:43:08 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id F13C1610E8 for ; Mon, 18 Oct 2021 04:43:07 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org F13C1610E8 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=sifive.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=nongnu.org Received: from localhost ([::1]:32840 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mcKUM-0001SM-59 for qemu-devel@archiver.kernel.org; Mon, 18 Oct 2021 00:43:07 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:43104) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mcJga-0005Ie-94 for qemu-devel@nongnu.org; Sun, 17 Oct 2021 23:51:40 -0400 Received: from mail-io1-xd33.google.com ([2607:f8b0:4864:20::d33]:37686) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mcJgT-0003z5-VP for qemu-devel@nongnu.org; Sun, 17 Oct 2021 23:51:39 -0400 Received: by mail-io1-xd33.google.com with SMTP id m20so14600280iol.4 for ; Sun, 17 Oct 2021 20:51:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sifive.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=fL1+dtG3QA+7ouU/u8eZLvzSKEbAzc51F8KF1GoSFYI=; b=DnPPxFnUyxgSrixZYT1y+b+MzyTEjaj+41SiSaq5ijAEaMbi/MKk4qK3LaCgHXwEE4 mJwKzIFtoninHUTMZUQ6BRvf8TRFkZXgwL9/w2zftl5QXWPC/CeKJvMqA38B6GwSt9zn OIogkP1OJ9CCEEr7RXnw2P8H35iGZM2GDruftue78QWsQPw4PdE4ahSaMtSBkX7HjM6N 2Q4GMRnccTai0qFLJyHKZMvVDdUH/slsihuomPeKwtXGnognMutob7LKfAxq133erUZp 6V5/i9XSlYDHuxLPC5ddQ6eGvxxfS8wNuPQhMH+FG3uVwD/Rug4zp/M+x0ubsOipwXxO 7g+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=fL1+dtG3QA+7ouU/u8eZLvzSKEbAzc51F8KF1GoSFYI=; b=LhvuxIZqbt6em4FX8fza83fEctPxGU9PbmuvN9zVG3c+BVjjmOLgi5yEzAGyS7BIll S2dT29S+pMkVdmLu9TSxWLK1eY08ljgyet0WgaEXihHDtf1l/d8J0HZ3AFAhVZpWsfyY AI7y+LzE+jW7CM25n58Um0aGbMHej5eaPO42UKgDRHCnowDDioZx1a6Jgc2P97J5YzCb mrR1/vQgcjbx0ZWIOncyGXdgpPtNJ0I9YURvy5sczgexYMlfEWqdJoVDqChn41bfXjTp ZdefwDufhA5pEErTFdD/38UfDNFtNQBp3KqZ+5+n1ppwH6OwUoaceDCfwHoOeB2i0nwm Eu6w== X-Gm-Message-State: AOAM53186dDeiC5nV5D63YbGoiTm4SIJbALzlA40eUG+18Wv5zp0tQte EAAoDX/M0RSV23NQMmx2WEcLi9dUSyojruuXbNwXmw== X-Google-Smtp-Source: ABdhPJxmQE10zsCINLmhbRroAoq7Y4F62YcJbku3AioIMDnKI4qNndePPTLHtRFp+tmxnzSMz8fF508Qbsrfwvn7Z08= X-Received: by 2002:a5d:9256:: with SMTP id e22mr12702683iol.152.1634529092904; Sun, 17 Oct 2021 20:51:32 -0700 (PDT) MIME-Version: 1.0 References: <20211015065500.3850513-1-frank.chang@sifive.com> <20211015065500.3850513-3-frank.chang@sifive.com> <4b718269-b222-c08f-ca72-656bacc31331@linaro.org> <2ac1b2bd-efa9-2005-5c0a-cace9346cbd7@linaro.org> In-Reply-To: From: Frank Chang Date: Mon, 18 Oct 2021 11:51:22 +0800 Message-ID: Subject: Re: [PATCH v3 2/2] target/riscv: change the api for single/double fmin/fmax To: Alistair Francis Content-Type: multipart/alternative; boundary="000000000000f53c3e05ce98759f" Received-SPF: pass client-ip=2607:f8b0:4864:20::d33; envelope-from=frank.chang@sifive.com; helo=mail-io1-xd33.google.com X-Spam_score_int: -16 X-Spam_score: -1.7 X-Spam_bar: - X-Spam_report: (-1.7 / 5.0 requ) BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "open list:RISC-V" , Bin Meng , Richard Henderson , "qemu-devel@nongnu.org Developers" , Chih-Min Chao , Alistair Francis , Palmer Dabbelt Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" --000000000000f53c3e05ce98759f Content-Type: text/plain; charset="UTF-8" On Mon, Oct 18, 2021 at 8:18 AM Alistair Francis wrote: > On Sun, Oct 17, 2021 at 4:59 PM Frank Chang > wrote: > > > > On Sun, Oct 17, 2021 at 8:55 AM Frank Chang > 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 > >>> > > wrote: > >>> > > >>> > On 10/14/21 11:54 PM, frank.chang@sifive.com frank.chang@sifive.com> wrote: > >>> > > From: Chih-Min Chao chihmin.chao@sifive.com>> > >>> > > > >>> > > The sNaN propagation behavior has been changed since > >>> > > cd20cee7 inhttps://github.com/riscv/riscv-isa-manual > >>> > > >>> > > > >>> > > Signed-off-by: Chih-Min Chao 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 > A little problem with Unpriv spec is that it uses v2.2 and later with the date as of version tag. It shouldn't be a real problem because we can still use the date v2.2. was released. But if it's okay to tie RVF version with Priv spec version, then let's just use Priv spec version for now. We can introduce other version variables when we really need them in the future. Thanks, Frank Chang > > > > > 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~ > --000000000000f53c3e05ce98759f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Oct 18, 2021 at 8:18 AM Alistair = Francis <alistair23@gmail.com> wrote:
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@lin= aro.org> wrote:
>>>
>>> On 10/16/21 1:52 AM, Frank Chang wrote:
>>> > On Sat, Oct 16, 2021 at 1:05 AM Richard Henderson <richard.hend= erson@linaro.org
>>> > <mailto:richard.henderson@linaro.org>> wrote:
>>> >
>>> >=C2=A0 =C2=A0 =C2=A0On 10/14/21 11:54 PM, frank.chang@sifive.com <= mailto:frank.ch= ang@sifive.com> wrote:
>>> >=C2=A0 =C2=A0 =C2=A0 > From: Chih-Min Chao<chihmin.chao@sifive.c= om <mailto:chihmin.chao@sifive.com>>
>>> >=C2=A0 =C2=A0 =C2=A0 >
>>> >=C2=A0 =C2=A0 =C2=A0 > The sNaN propagation behavior ha= s been changed since
>>> >=C2=A0 =C2=A0 =C2=A0 > cd20cee7 inhttps://github.com/riscv/riscv-isa-manual
>>> >=C2=A0 =C2=A0 =C2=A0<http://github.com/r= iscv/riscv-isa-manual>
>>> >=C2=A0 =C2=A0 =C2=A0 >
>>> >=C2=A0 =C2=A0 =C2=A0 > Signed-off-by: Chih-Min Chao<= chihmin.chao@s= ifive.com <mailto:chihmin.chao@sifive.com>>
>>> >=C2=A0 =C2=A0 =C2=A0 > ---
>>> >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0target/riscv/fpu_hel= per.c | 8 ++++----
>>> >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A01 file changed, 4 in= sertions(+), 4 deletions(-)
>>> >=C2=A0 =C2=A0 =C2=A0 >
>>> >=C2=A0 =C2=A0 =C2=A0 > diff --git a/target/riscv/fpu_he= lper.c b/target/riscv/fpu_helper.c
>>> >=C2=A0 =C2=A0 =C2=A0 > index 8700516a14c..1472ead2528 1= 00644
>>> >=C2=A0 =C2=A0 =C2=A0 > --- a/target/riscv/fpu_helper.c<= br> >>> >=C2=A0 =C2=A0 =C2=A0 > +++ b/target/riscv/fpu_helper.c<= br> >>> >=C2=A0 =C2=A0 =C2=A0 > @@ -174,14 +174,14 @@ uint64_t h= elper_fmin_s(CPURISCVState *env, uint64_t rs1,
>>> >=C2=A0 =C2=A0 =C2=A0uint64_t rs2)
>>> >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0{
>>> >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0float3= 2 frs1 =3D check_nanbox_s(rs1);
>>> >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0float3= 2 frs2 =3D check_nanbox_s(rs2);
>>> >=C2=A0 =C2=A0 =C2=A0 > -=C2=A0 =C2=A0 return nanbox_s(f= loat32_minnum(frs1, frs2, &env->fp_status));
>>> >=C2=A0 =C2=A0 =C2=A0 > +=C2=A0 =C2=A0 return nanbox_s(f= loat32_minnum_noprop(frs1, frs2, &env->fp_status));
>>> >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0}
>>> >
>>> >=C2=A0 =C2=A0 =C2=A0Don't you need to conditionalize b= ehaviour on the isa revision?
>>> >
>>> >
>>> > I will pick the right API based on CPU privilege spec ver= sion.
>>>
>>> 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 com= mit: #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_VERSI= ON_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

A little problem with Unpriv s= pec is that it uses v2.2 and later with the date as of version tag.
It shouldn't be a real problem because we can still use the date v2.= 2. was released.

But if it's okay to tie RVF v= ersion with Priv spec version,
then let's just use Priv spec = version for now.
We can introduce other version variables when we= really need them in the future.

Thanks,
Frank Chang
=C2=A0

>
> 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-v= 1.11
>>
>> In fact, Unprivileged spec v2.2 was released at (2017/05/10):
>> https://github.com/ris= cv/riscv-isa-manual/releases/tag/riscv-user-2.2
>>
>> and Privilege spec v1.10 was released at (2017/05/10):
>> https://github.com/ri= scv/riscv-isa-manual/releases/tag/riscv-priv-1.10
>>
>> Privilege spec was then bumped to v1.11-draft in the next draft re= lease 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_ve= r.
>> 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~
--000000000000f53c3e05ce98759f--