diff options
Diffstat (limited to 'src/zfinx.tex')
| -rw-r--r-- | src/zfinx.tex | 66 |
1 files changed, 42 insertions, 24 deletions
diff --git a/src/zfinx.tex b/src/zfinx.tex index 8354761..d5edf1d 100644 --- a/src/zfinx.tex +++ b/src/zfinx.tex @@ -2,10 +2,9 @@ \label{sec:zfinx} This chapter defines the ``Zfinx'' extension (pronounced ``z-f-in-x''), which -redefines the instructions in the standard floating-point extensions -(including F, D, Q, and Zfh) to operate on the {\tt x} registers, rather than -the {\tt f} registers. -The Zfinx extension depends on the F extension. +provides instructions similar to those in the standard floating-point +extensions, but that operate on the {\tt x} registers instead of the {\tt f} +registers. \begin{commentary} The baseline F extension uses separate {\tt f} registers for floating-point @@ -15,7 +14,8 @@ register-file ports for wide superscalars. However, the additional \wunits{128}{B} of architectural state increases the minimal implementation cost. By eliminating the {\tt f} registers, the Zfinx extension substantially -reduces the cost of simple RISC-V implementations. +reduces the cost of simple RISC-V implementations with floating-point +instruction-set support. Unlike most RISC-V extensions, the addition of Zfinx is not backwards compatible: software that uses floating-point instructions but assumes the @@ -23,11 +23,9 @@ absence of the Zfinx extension will not, in general, execute correctly on implementations with the Zfinx extension. \end{commentary} -The Zfinx extension {\em removes} the floating-point load, store, and -integer-transfer instructions (FL[HWDQ], FS[HWDQ], FMV.[HWDQ].X and -FMV.X.[HWDQ]) and corresponding C-extension instructions (C.FL[WD], -C.FL[WD]SP, C.FS[WD], C.FS[WD]SP). -The opcodes corresponding to the removed instructions are {\em reserved}. +The Zfinx extension adds all of the instructions that the F extension +adds, {\em except} for the transfer instructions FLW, FSW, FMV.W.X, +FMV.X.W, C.FLW[SP], and C.FSW[SP]. \begin{commentary} Zfinx software uses integer loads and stores to transfer floating-point values @@ -36,13 +34,9 @@ Transfers between registers use either integer arithmetic or floating-point sign-injection instructions. \end{commentary} -The Zfinx extension {\em redefines} all instructions that access {\tt f} -registers to instead access the {\tt x} register with the same number. - -In the standard privileged architecture defined in Volume II, the -{\tt mstatus} field FS is hardwired to 0 if the Zfinx extension is -implemented, and FS no longer affects the trapping behavior of -floating-point instructions or {\tt fcsr} accesses. +The Zfinx variants of these F-extension instructions have the same semantics, +except that whenever such an instruction would have accessed an {\tt f} +register, it instead accesses the {\tt x} register with the same number. \section{NaN Boxing of Narrower Values} @@ -62,29 +56,53 @@ We retain the NaN-boxing of results to keep Zfinx as similar as possible and to ease debugging. \end{commentary} +\section{Zdinx} + +The Zdinx extension provides analogous double-precision floating-point +instructions. +The Zdinx extension requires the Zfinx extension. + +The Zdinx extension adds all of the instructions that the D extension +adds, {\em except} for the transfer instructions FLD, FSD, FMV.D.X, +FMV.X.D, C.FLD[SP], and C.FSD[SP]. + +The Zdinx variants of these D-extension instructions have the same semantics, +except that whenever such an instruction would have accessed an {\tt f} +register, it instead accesses the {\tt x} register with the same number. + \section{Processing of Wider Values} -Double-precision operands in RV32DZfinx and quad-precision operands -in RV64QZfinx are held in aligned {\tt x}-register pairs, i.e., +Double-precision operands in RV32Zdinx +are held in aligned {\tt x}-register pairs, i.e., register numbers must be even. Use of misaligned (odd-numbered) registers for double-width floating-point operands is {\em reserved}. Regardless of endianness, the lower-numbered register holds the low-order bits, and the higher-numbered register holds the high-order bits: e.g., bits -31:0 of a double-precision operand in RV32DZfinx might be held in register +31:0 of a double-precision operand in RV32Zdinx might be held in register {\tt x14}, with bits 63:32 of that operand held in {\tt x15}. When a double-width floating-point result is written to {\tt x0}, the entire -write takes no effect: e.g., for RV32DZfinx, writing a double-precision result +write takes no effect: e.g., for RV32Zdinx, writing a double-precision result to {\tt x0} preserves the contents of {\tt x1}. \begin{commentary} Load-pair and store-pair instructions are not provided, so transferring -double-precision operands in RV32DZfinx from or to memory requires +double-precision operands in RV32Zdinx from or to memory requires two loads or stores. Register moves need only a single FSGNJ.D instruction, however. \end{commentary} -Quad-precision operands in RV32QZfinx are handled analogously, with -a four-register alignment requirement. +\section{Zqinx} + +The Zqinx extension is defined analogously to the Zdinx extension. +For RV64, quad-precision operands require two-register alignment. +For RV32, quad-precision operands require four-register alignment. + +\section{Privileged Architecture Implications} + +In the standard privileged architecture defined in Volume II, the +{\tt mstatus} field FS is hardwired to 0 if the Zfinx extension is +implemented, and FS no longer affects the trapping behavior of +floating-point instructions or {\tt fcsr} accesses. |