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

[Frank Chang]

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).

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~