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

[Frank Chang <frank.chang@sifive.com>]

[-- Attachment #1: Type: text/plain, Size: 4130 bytes --]

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
> <https://github.com/riscv/riscv-isa-manual/commit/cd20cee7efd9bac7c5aa127ec3b451749d2b3cce>
>  (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).

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~
>>
>

[-- Attachment #2: Type: text/html, Size: 7294 bytes --]