[libre-riscv-dev] fp special functions

[Luke Kenneth Casson Leighton]

atif: i approved you for being able to "send" to libre-riscv-dev,
we'll try to keep you cc'd for relevant discussion (the list can get a
bit busy at times).

i went over the FP major opcode 1010011 yesterday, and there is a huge
amount of "brownfield" space available: 50% of the funct7 fields are
entirely free, under 5% of funct7 is fully taken up (FADD, FSUB, FMUL,
FDIV), and the remaining 45-ish% are sparsely populated.

by contrast, the RVV opcode space is almost entirely taken up, with
"vectorised" versions of (otherwise) scalar operations that
effectively duplicate much of xBitManip (used for predicate masks,
except as zero-non-zero elements rather than individual bits), and the
necessary INT/FP opcodes also duplicate scalar and take up space as
well.

i went over the slides you sent me yesterday (can we put those online
somewhere?) and made a preliminary effort of filling in some of the
transcendentals from the slides you sent me:
https://libre-riscv.org/rv_major_opcode_1010011/

i'll fill in some of jacob's ideas as well, to see what that looks like.

Jacob wrote:

> I think we should have our primitive instructions be correctly rounded,
> since, for all but sin/cos/tan/sec/cosec/cotan, that doesn't take much more
> precision.

yes, agreed.  if you look at the table, there are places
(funct5=NNNNN) where fmt (funct3) is used for "rounding mode".  these
may turn out to be quite precious, so we have to be careful.

yesterday i spotted that in the Zfrsqrt proposal that you'd started an
entire new funct5 for FRSQRT, where it would be better to put it right
next to FSQRT, with rs2=00001 instead.
see https://groups.google.com/a/groups.riscv.org/d/msg/isa-dev/SLprSJzpgCQ/93AW5prUFAAJ

> I think we should implement sinpi/cospi and friends since they
> avoid the need to have an extremely (several hundred bit) accurate version
> of pi.

i love pi.  must memorise a few more digits just... because :)  sorry,
yes, agreed, good suggestion.

l.