[Libre-soc-bugs] [Bug 1135] New: add FPSCR and Rounding classes to ieee754fpu
bugzilla-daemon at libre-soc.org
bugzilla-daemon at libre-soc.org
Thu Aug 10 00:28:50 BST 2023
https://bugs.libre-soc.org/show_bug.cgi?id=1135
Bug ID: 1135
Summary: add FPSCR and Rounding classes to ieee754fpu
Product: Libre-SOC's first SoC
Version: unspecified
Hardware: PC
OS: Linux
Status: CONFIRMED
Severity: enhancement
Priority: ---
Component: ALU (including IEEE754 16/32/64-bit FPU)
Assignee: programmerjake at gmail.com
Reporter: programmerjake at gmail.com
CC: libre-soc-bugs at lists.libre-soc.org,
programmerjake at gmail.com
Blocks: 1134
NLnet milestone: ---
to allow FP ops to compute in parallel despite each fp op semantically reading
the FPSCR output from the previous op, the FPSCR will be split into 3 parts (I
picked names that aren't necessarily standard names):
* volatile part: written nearly every insn but is rarely read
FR, FI, FPRF
* sticky part: generally doesn't change but is read and written by nearly all
insns:
all the sticky exception bits
* control part: generally doesn't change and is only read by nearly all insns:
all the other bits
the above is all that will be implemented as part of this task, all of the
below is just explaining why we should split FPSCR into parts:
the idea is that the cpu will have all three parts in separate registers and
will speculatively execute fp insns with the current value of the sticky part
register (not the one from the previous instruction, but the one from the
register, avoiding needing a dependency chain), and then will cancel and retry
all later insns if it turns out that the insn changed the sticky part (which is
rare).
if desired the control part can be put in the same register and handled the
same way as the sticky part, but this makes code that temporarily changes the
rounding mode slower than necessary (common in x87 emulation and some math
library functions).
Referenced Bugs:
https://bugs.libre-soc.org/show_bug.cgi?id=1134
[Bug 1134] implement fminmax in ieee754fpu
--
You are receiving this mail because:
You are on the CC list for the bug.
More information about the libre-soc-bugs
mailing list