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