On Sun, Oct 17, 2021 at 8:55 AM Frank Chang <frank.ch...@sifive.com> wrote:
> On Sun, Oct 17, 2021 at 1:56 AM Richard Henderson < > richard.hender...@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.hender...@linaro.org >> > <mailto:richard.hender...@linaro.org>> wrote: >> > >> > On 10/14/21 11:54 PM, frank.ch...@sifive.com <mailto: >> frank.ch...@sifive.com> wrote: >> > > From: Chih-Min Chao<chihmin.c...@sifive.com <mailto: >> chihmin.c...@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.c...@sifive.com <mailto: >> chihmin.c...@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~ >> >
