1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
|
[[sec:zfinx]]
== "Zfinx", "Zdinx", "Zhinx", "Zhinxmin" Extensions for Floating-Point in Integer Registers, Version 1.0
This chapter defines the "Zfinx" extension (pronounced "z-f-in-x")
that provides instructions similar to those in the standard
floating-point F extension for single-precision floating-point
instructions but which operate on the `x` registers instead of the `f`
registers. This chapter also defines the "Zdinx", "Zhinx", and
"Zhinxmin" extensions that provide similar instructions for other
floating-point precisions.
[NOTE]
====
The F extension uses separate `f` registers for floating-point
computation, to reduce register pressure and simplify the provision of
register-file ports for wide superscalars. However, the additional of
architectural state increases the minimal implementation cost. By
eliminating the `f` registers, the Zfinx extension substantially reduces
the cost of simple RISC-V implementations with floating-point
instruction-set support. Zfinx also reduces context-switch cost.
In general, software that assumes the presence of the F extension is
incompatible with software that assumes the presence of the Zfinx
extension, and vice versa.
====
The Zfinx extension adds all of the instructions that the F extension
adds, _except_ for the transfer instructions FLW, FSW, FMV.W.X, FMV.X.W,
C.FLW[SP], and C.FSW[SP].
[NOTE]
====
Zfinx software uses integer loads and stores to transfer floating-point
values from and to memory. Transfers between registers use either
integer arithmetic or floating-point sign-injection instructions.
====
The Zfinx variants of these F-extension instructions have the same
semantics, except that whenever such an instruction would have accessed
an `f` register, it instead accesses the `x` register with the same
number.
The Zfinx extension depends on the "Zicsr" extension for control and status register access.
=== Processing of Narrower Values
Floating-point operands of width _w_ latexmath:[$<$] XLEN bits occupy
bits _w_-1:0 of an `x` register. Floating-point operations on _w_-bit
operands ignore operand bits XLEN-1: _w_.
Floating-point operations that produce _w_ latexmath:[$<$] XLEN-bit
results fill bits XLEN-1: _w_ with copies of bit _w_-1 (the sign bit).
[NOTE]
====
The NaN-boxing scheme employed in the `f` registers was designed to
efficiently support recoded floating-point formats. Recoding is less
practical for Zfinx, though, since the same registers hold both
floating-point and integer operands. Hence, the need for NaN boxing is
diminished.
Sign-extending 32-bit floating-point numbers when held in RV64 `x`
registers is compatible with the existing RV64 calling conventions, which leave bits 63-32 undefined when passing a 32-bit floating point value in `x` registers. To keep the architecture more regular, we extend this pattern to 16-bit floating-point numbers in both RV32 and RV64.
====
=== 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, _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 `f` register, it instead accesses the `x` register with the same
number.
=== Processing of Wider Values
Double-precision operands in RV32Zdinx are held in aligned `x`-register
pairs, i.e., register numbers must be even. Use of misaligned
(odd-numbered) registers for double-width floating-point operands is
_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 RV32Zdinx might
be held in register `x14`, with bits 63:32 of that operand held in
`x15`.
When a double-width floating-point result is written to `x0`, the entire
write takes no effect: e.g., for RV32Zdinx, writing a double-precision
result to `x0` does not cause `x1` to be written.
When `x0` is used as a double-width floating-point operand, the entire
operand is zero—i.e., `x1` is not accessed.
[NOTE]
====
Load-pair and store-pair instructions are not provided, so transferring
double-precision operands in RV32Zdinx from or to memory requires two
loads or stores. Register moves need only a single FSGNJ.D instruction,
however.
====
=== Zhinx
The Zhinx extension provides analogous half-precision floating-point
instructions. The Zhinx extension requires the Zfinx extension.
The Zhinx extension adds all of the instructions that the Zfh extension
adds, _except_ for the transfer instructions FLH, FSH, FMV.H.X, and
FMV.X.H.
The Zhinx variants of these Zfh-extension instructions have the same
semantics, except that whenever such an instruction would have accessed
an `f` register, it instead accesses the `x` register with the same
number.
=== Zhinxmin
The Zhinxmin extension provides minimal support for 16-bit
half-precision floating-point instructions that operate on the `x`
registers. The Zhinxmin extension requires the Zfinx extension.
The Zhinxmin extension includes the following instructions from the
Zhinx extension: FCVT.S.H and FCVT.H.S. If the Zdinx extension is
present, the FCVT.D.H and FCVT.H.D instructions are also included.
[NOTE]
====
In the future, an RV64Zqinx quad-precision extension could be defined
analogously to RV32Zdinx. An RV32Zqinx extension could also be defined
but would require quad-register groups.
====
=== Privileged Architecture Implications
In the standard privileged architecture defined in Volume II, the
`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 `fcsr` accesses.
The `misa` bits F, D, and Q are hardwired to 0 when the Zfinx extension
is implemented.
[NOTE]
====
A future discoverability mechanism might be used to probe the existence
of the Zfinx, Zhinx, and Zdinx extensions.
====
|
