Bug 110 - RISC-V FP Reciprocal (inverse) square root ISA extension needed
Summary: RISC-V FP Reciprocal (inverse) square root ISA extension needed
Status: CONFIRMED
Alias: None
Product: Libre-SOC's first SoC
Classification: Unclassified
Component: Specification (show other bugs)
Version: unspecified
Hardware: Other Linux
: --- enhancement
Assignee: Luke Kenneth Casson Leighton
URL:
Depends on:
Blocks: 44
  Show dependency treegraph
 
Reported: 2019-07-12 09:34 BST by Luke Kenneth Casson Leighton
Modified: 2019-08-04 07:00 BST (History)
2 users (show)

See Also:
NLnet milestone: NLnet.2019.02
total budget (EUR) for completion of task and all subtasks: 0
budget (EUR) for this task, excluding subtasks' budget: 0
parent task for budget allocation:
child tasks for budget allocation:
The table of payments (in EUR) for this task; TOML format:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Luke Kenneth Casson Leighton 2019-07-12 09:34:01 BST
http://lists.libre-riscv.org/pipermail/libre-riscv-dev/2019-July/002018.html

I propose a Zfrsqrt extension that consists of the frsqrt.s, frsqrt.d,
frsqrt.q, and frsqrt.h instructions, where the 32-bit, 64-bit,
128-bit, and 16-bit versions require the corresponding F, D, Q, etc.
extensions.
If only the F and Zfrsqrt extensions are supported, then only the
frsqrt.s instruction is supported.
If only the F, D, and Zfrsqrt extensions are supported, then only the
frsqrt.s and the frsqrt.d instructions are supported. Likewise for
frsqrt.q and frsqrt.h requiring the corresponding extensions enabled.

The operation implemented by frsqrt.* is a correctly-rounded
implementation of the IEEE 754-2008 rSqrt operation, with all the
usual FP rounding modes supported.

For the encoding, I think using an encoding similar to both the
fsqrt.* and fdiv.* encodings is a good idea, since frsqrt is similar
to both fdiv and fsqrt; Therefore, as an initial proposal, I think
using a funct7 value of 0111100 and the rest of the instruction
identical to fsqrt is a good idea, since, as far as I'm aware, that
doesn't conflict with anything currently.

We (libre-riscv.org) are currently planning on implementing frsqrt in
our libre GPU, since frsqrt is a common operation in 3D graphics (used
for vector normalization, among other things).

Comments, modifications, etc. welcome.
Comment 1 Luke Kenneth Casson Leighton 2019-08-04 06:34:59 BST
FRSQRT.S would need to be funct7=0b0111100
FRSQRT.D would need to be funct7=0b0111101
FRSQRT.Q would need to be funct7=0b0111111
FRSQRT.H would need to be funct7=0b0111110 

lower 2 bits of funct7 select the bitwidth.  upper 5 bits set the function.

(edited to use correct funct7 values)
Comment 2 Luke Kenneth Casson Leighton 2019-08-04 06:57:14 BST
+----------+---------+-------+-----+--------+----+---------+
| Mnemonic | funct7  | rs2   | rs1 | funct3 | rd | opcode  |
+==========+=========+=======+=====+========+====+=========+
| fsqrt.s  | 0111100 | 00000 | rs1 | rm     | rd | 1010011 |
+----------+---------+-------+-----+--------+----+---------+
| fsqrt.d  | 0111101 | 00000 | rs1 | rm     | rd | 1010011 |
+----------+---------+-------+-----+--------+----+---------+
| fsqrt.q  | 0111110 | 00000 | rs1 | rm     | rd | 1010011 |
+----------+---------+-------+-----+--------+----+---------+
| fsqrt.h  | 0111111 | 00000 | rs1 | rm     | rd | 1010011 |
+----------+---------+-------+-----+--------+----+---------+