From: Frank Chang <frank.chang@sifive.com>

Zfh - Half width floating point
Zfhmin - Subset of half width floating point

Zfh, Zfhmin v0.1 is now in public review period and is required by
RVV extension:
https://groups.google.com/a/groups.riscv.org/g/isa-dev/c/63gDCinXTwE/m/871Wm9XIBQAJ

Zfh, Zfhmin can be enabled with -cpu option: Zfh=true and Zfhmin=true
respectively.

The port is available at:
https://github.com/sifive/qemu/tree/zfh-upstream-v3

Note: This patchset depends on another patchset listed in Based-on
      section below so it is not able to be built unless the patchset
      is applied.

Changelog:

v3:
  * Use the renamed softfloat min/max APIs: *_minimum_number()
    and *_maximum_number().
  * Pick softfloat min/max APIs based on CPU privilege spec version.
  * Add braces for if statements in REQUIRE_ZFH() and
    REQUIRE_ZFH_OR_ZFHMIN().
  * Rearrange the positions of Zfh and Zfhmin cpu properties.

v2:
  * Use {get,dest}_gpr APIs.
  * Add Zfhmin extension.

Based-on: <20211016085428.3001501-1-frank.chang@sifive.com>

Frank Chang (1):
  target/riscv: zfh: implement zfhmin extension

Kito Cheng (5):
  target/riscv: zfh: half-precision load and store
  target/riscv: zfh: half-precision computational
  target/riscv: zfh: half-precision convert and move
  target/riscv: zfh: half-precision floating-point compare
  target/riscv: zfh: half-precision floating-point classify

 target/riscv/cpu.c                        |   2 +
 target/riscv/cpu.h                        |   2 +
 target/riscv/fpu_helper.c                 | 180 ++++++++
 target/riscv/helper.h                     |  29 ++
 target/riscv/insn32.decode                |  38 ++
 target/riscv/insn_trans/trans_rvzfh.c.inc | 537 ++++++++++++++++++++++
 target/riscv/internals.h                  |  16 +
 target/riscv/translate.c                  |  20 +
 8 files changed, 824 insertions(+)
 create mode 100644 target/riscv/insn_trans/trans_rvzfh.c.inc

--
2.25.1

On 10/16/21 2:07 AM, frank.chang@sifive.com wrote:
> Changelog:
> 
> v3:
>    * Use the renamed softfloat min/max APIs: *_minimum_number()
>      and *_maximum_number().
>    * Pick softfloat min/max APIs based on CPU privilege spec version.

So... Given that Zfh 0.1 post-dates F 2.2, does that mean that Zfh should always use the 
2019 functions?


r~

On Sun, Oct 17, 2021 at 2:03 AM Richard Henderson <
richard.henderson@linaro.org> wrote:

> On 10/16/21 2:07 AM, frank.chang@sifive.com wrote:
> > Changelog:
> >
> > v3:
> >    * Use the renamed softfloat min/max APIs: *_minimum_number()
> >      and *_maximum_number().
> >    * Pick softfloat min/max APIs based on CPU privilege spec version.
>
> So... Given that Zfh 0.1 post-dates F 2.2, does that mean that Zfh should
> always use the
> 2019 functions?
>

Hi Richard,

That's what I thought, but Zfh spec says:

"This chapter describes the Zfh standard extension for 16-bit
half-precision binary floating-point
instructions compliant with the IEEE 754-2008 arithmetic standard. The Zfh
extension depends on
the single-precision floating-point extension, F."

The spec doesn't illustrate too much about how fmin.h/fmax.h should behave,
so that's why I took the same approach just like fmin and fmax for RVF in
my other patchset.

If that's not acceptable, I can change back to use IEEE 754-2019 for Zfh
extension.

Thanks,
Frank Chang


>
> r~
>