(no commit message)
[libreriscv.git] / simple_v_extension / sv_prefix_proposal.rst
1 SimpleV Prefix (SVprefix) Proposal v0.3
2 =======================================
3
4 This proposal is designed to be able to operate without SVorig, but not to
5 require the absence of SVorig See Specification_.
6
7 .. _Specification: http://libre-riscv.org/simple_v_extension/specification/
8
9 .. contents::
10
11 Conventions
12 ===========
13
14 Conventions used in this document:
15 - Bits are numbered starting from 0 at the LSB, so bit 3 is 1 in the integer 8.
16 - Bit ranges are inclusive on both ends, so 5:3 means bits 5, 4, and 3.
17
18 Operations work on variable-length vectors of sub-vectors, where each sub-vector
19 has a length *svlen*, and an element type *etype*. When the vectors are stored
20 in registers, all elements are packed so that there is no padding in-between
21 elements of the same vector. The number of bytes in a sub-vector, *svsz*, is the
22 product of *svlen* and the element size in bytes.
23
24 Options
25 =======
26
27 * SVPrefix augments the main Specification_
28 * SVPregix operates independently, without the VL (and MVL) CSRs (in any priv level)
29 * SVPrefix operates independently, without the SUBVL CSRs (in any priv level)
30 * SVPrefix operates independently, with no support for VL (or MVL) overrides in the 64 bit instruction format either (VLtyp=0)
31 * SVPrefix operates independently, with no support for svlen overrides in either the 48 or 64 bit instruction format either (svlen=0).
32
33 All permutations of the above options are permitted, and in the UNIX platform must raise illegal instruction exceptions on implementations that do not support them.
34
35 Note that allowing interaction with VL/MVL (and SUBVL) CSRs is **NOT** the same as supporting VLtyp (or svlen) overrides that are embedded in the 48/64 opcodes. As overrides, setting of VLtyp (or svlen) requires a **completely separate** CSR from the main Specification_ STATE CSR, named SVPSTATE.
36
37 If the nain Specification_ CSRs are to be supported, the STATE, VL, MVL and SUBVL CSRs all operate according to the main specification. Under the options above, hypothetically an implementor could choose not to support setting of VL, MVL or SUBVL (only allowing them to be set to a value of 1). Under such circumstances, where *neither* VL/MVL *nor* SUBVL are supported, STATE would then not be required either.
38
39 If however support for SUBVL is to be provided, storing of the sub-vector offsets and SUBVL itself (and context switching of the same) in the STATE CSRs are mandatory.
40
41 Likewise if support for VL is to be provided, storing of VL, MVL and the dest and src offsets (and context switching of the same) in the STATE CSRs are mandatory.
42
43 This completely independently of SVPSTATE, svlen and VLtyp, as these are instruction-specific overrides that do **not** affect STATE.
44
45 Half-Precision Floating Point (FP16)
46 ====================================
47
48 If the F extension is supported, SVprefix adds support for FP16 in the
49 base FP instructions by using 10 (H) in the floating-point format field *fmt*
50 and using 001 (H) in the floating-point load/store *width* field.
51
52 Compressed Instructions
53 =======================
54 This proposal does not include any prefixed RVC instructions, instead, it will
55 include 32-bit instructions that are compressed forms of SVprefix 48-bit
56 instructions, in the same manner that RVC instructions are compressed forms of
57 RVI instructions. The compressed instructions will be defined later by
58 considering which 48-bit instructions are the most common.
59
60 48-bit Prefixed Instructions
61 ============================
62 All 48-bit prefixed instructions contain a 32-bit "base" instruction as the
63 last 4 bytes. Since all 32-bit instructions have bits 1:0 set to 11, those bits
64 are reused for additional encoding space in the 48-bit instructions.
65
66 64-bit Prefixed Instructions
67 ============================
68
69 The 48 bit format is further extended with the full 128-bit range on all source
70 and destination registers, and the option to set both VL and MVL is provided.
71
72 48-bit Instruction Encodings
73 ============================
74
75 In the following table, *Reserved* entries must be zero. RV32 equivalent encodings
76 included for side-by-side comparison (and listed below, separately).
77
78 First, bits 17:0:
79
80 +---------------+--------+------------+------------+-----+------------+-------------+------+------------+--------+
81 | Encoding | 17 | 16 | 15 | 14 | 13 | 12 | 11:7 | 6 | 5:0 |
82 +---------------+--------+------------+------------+-----+------------+-------------+------+------------+--------+
83 | P48-LD-type | rd[5] | rs1[5] | vitp7[6] | vd | vs1 | vitp7[5:0] | *Reserved* | 011111 |
84 +---------------+--------+------------+------------+-----+------------+-------------+------+------------+--------+
85 | P48-ST-type |vitp7[6]| rs1[5] | rs2[5] | vs2 | vs1 | vitp7[5:0] | *Reserved* | 011111 |
86 +---------------+--------+------------+------------+-----+------------+-------------+------+------------+--------+
87 | P48-R-type | rd[5] | rs1[5] | rs2[5] | vs2 | vs1 | vitp6 | *Reserved* | 011111 |
88 +---------------+--------+------------+------------+-----+------------+--------------------+------------+--------+
89 | P48-I-type | rd[5] | rs1[5] | vitp7[6] | vd | vs1 | vitp7[5:0] | *Reserved* | 011111 |
90 +---------------+--------+------------+------------+-----+------------+--------------------+------------+--------+
91 | P48-U-type | rd[5] | *Reserved* | *Reserved* | vd | *Reserved* | vitp6 | *Reserved* | 011111 |
92 +---------------+--------+------------+------------+-----+------------+-------------+------+------------+--------+
93 | P48-FR-type | rd[5] | rs1[5] | rs2[5] | vs2 | vs1 | *Reserved* | vtp5 | *Reserved* | 011111 |
94 +---------------+--------+------------+------------+-----+------------+-------------+------+------------+--------+
95 | P48-FI-type | rd[5] | rs1[5] | vitp7[6] | vd | vs1 | vitp7[5:0] | *Reserved* | 011111 |
96 +---------------+--------+------------+------------+-----+------------+-------------+------+------------+--------+
97 | P48-FR4-type | rd[5] | rs1[5] | rs2[5] | vs2 | rs3[5] | vs3 [#fr4]_ | vtp5 | *Reserved* | 011111 |
98 +---------------+--------+------------+------------+-----+------------+-------------+------+------------+--------+
99
100 .. [#fr4] Only vs2 and vs3 are included in the P48-FR4-type encoding because
101 there is not enough space for vs1 as well, and because it is more
102 useful to have a scalar argument for each of the multiplication and
103 addition portions of fmadd than to have two scalars on the
104 multiplication portion.
105
106 Table showing correspondance between P48-*-type and RV32-*-type. These are
107 bits 47:18 (RV32 shifted up by 16 bits):
108
109 +---------------+---------------+
110 | Encoding | 47:18 |
111 +---------------+---------------+
112 | RV32 Encoding | 31:2 |
113 +---------------+---------------+
114 | P48-LD-type | RV32-I-type |
115 +---------------+---------------+
116 | P48-ST-type | RV32-S-Type |
117 +---------------+---------------+
118 | P48-R-type | RV32-R-Type |
119 +---------------+---------------+
120 | P48-I-type | RV32-I-Type |
121 +---------------+---------------+
122 | P48-U-type | RV32-U-Type |
123 +---------------+---------------+
124 | P48-FR-type | RV32-FR-Type |
125 +---------------+---------------+
126 | P48-FI-type | RV32-I-Type |
127 +---------------+---------------+
128 | P48-FR4-type | RV32-FR-type |
129 +---------------+---------------+
130
131 Table showing Standard RV32 encodings:
132
133 +---------------+-------------+-------+----------+----------+--------+----------+--------+--------+------------+
134 | Encoding | 31:27 | 26:25 | 24:20 | 19:15 | 14:12 | 11:7 | 6:2 | 1 | 0 |
135 +---------------+-------------+-------+----------+----------+--------+----------+--------+--------+------------+
136 | RV32-R-type + funct7 + rs2[4:0] + rs1[4:0] + funct3 | rd[4:0] + opcode + 1 + 1 |
137 +---------------+-------------+-------+----------+----------+--------+----------+--------+--------+------------+
138 | RV32-S-type + imm[11:5] + rs2[4:0] + rs1[4:0] + funct3 | imm[4:0] + opcode + 1 + 1 |
139 +---------------+-------------+-------+----------+----------+--------+----------+--------+--------+------------+
140 | RV32-I-type + imm[11:0] + rs1[4:0] + funct3 | rd[4:0] + opcode + 1 + 1 |
141 +---------------+-------------+-------+----------+----------+--------+----------+--------+--------+------------+
142 | RV32-U-type + imm[31:12] | rd[4:0] + opcode + 1 + 1 |
143 +---------------+-------------+-------+----------+----------+--------+----------+--------+--------+------------+
144 | RV32-FR4-type + rs3[4:0] + fmt + rs2[4:0] + rs1[4:0] + funct3 | rd[4:0] + opcode + 1 + 1 |
145 +---------------+-------------+-------+----------+----------+--------+----------+--------+--------+------------+
146 | RV32-FR-type + funct5 + fmt + rs2[4:0] + rs1[4:0] + rm | rd[4:0] + opcode + 1 + 1 |
147 +---------------+-------------+-------+----------+----------+--------+----------+--------+--------+------------+
148
149 64-bit Instruction Encodings
150 ============================
151
152 Where in the 48 bit format the prefix is "0b0011111" in bits 0 to 6, this is
153 now set to "0b0111111".
154
155 +---------------+---------------+--------------+-----------+
156 | 63:48 | 47:18 | 17:7 | 6:0 |
157 +---------------+---------------+--------------+-----------+
158 | 64 bit prefix | RV32[31:3] | P48[17:7] | 0b0111111 |
159 +---------------+---------------+--------------+-----------+
160
161 * The 64 bit prefix format is below
162 * Bits 18 to 47 contain bits 3 to 31 of a standard RV32 format
163 * Bits 7 to 17 contain bits 7 through 17 of the P48 format
164 * Bits 0 to 6 contain the standard RV 64-bit prefix 0b0111111
165
166 64 bit prefix format:
167
168 +--------------+-------+--------+--------+--------+--------+
169 | Encoding | 63 | 62 | 61 | 60 | 59:48 |
170 +--------------+-------+--------+--------+--------+--------+
171 | P64-LD-type | rd[6] | rs1[6] | | | VLtyp |
172 +--------------+-------+--------+--------+--------+--------+
173 | P64-ST-type | | rs1[6] | rs2[6] | | VLtyp |
174 +--------------+-------+--------+--------+--------+--------+
175 | P64-R-type | rd[6] | rs1[6] | rs2[6] | | VLtyp |
176 +--------------+-------+--------+--------+--------+--------+
177 | P64-I-type | rd[6] | rs1[6] | | | VLtyp |
178 +--------------+-------+--------+--------+--------+--------+
179 | P64-U-type | rd[6] | | | | VLtyp |
180 +--------------+-------+--------+--------+--------+--------+
181 | P64-FR-type | | rs1[6] | rs2[6] | | VLtyp |
182 +--------------+-------+--------+--------+--------+--------+
183 | P64-FI-type | rd[6] | rs1[6] | rs2[6] | | VLtyp |
184 +--------------+-------+--------+--------+--------+--------+
185 | P64-FR4-type | rd[6] | rs1[6] | rs2[6] | rs3[6] | VLtyp |
186 +--------------+-------+--------+--------+--------+--------+
187
188 The extra bit for src and dest registers provides the full range of
189 up to 128 registers, when combined with the extra bit from the 48 bit
190 prefix as well. VLtyp encodes how (whether) to set VL and MAXVL.
191
192 VLtyp field encoding
193 ====================
194
195 +-----------+-------------+--------------+----------+----------------------+
196 | VLtyp[11] | VLtyp[10:6] | VLtyp[5:1] | VLtyp[0] | comment |
197 +-----------+-------------+--------------+----------+----------------------+
198 | 0 | 000000 | 00000 | 0 | no change to VL/MVL |
199 +-----------+-------------+--------------+----------+----------------------+
200 | 0 | VLdest | VLEN | vlt | VL imm/reg mode (vlt)|
201 +-----------+-------------+--------------+----------+----------------------+
202 | 1 | VLdest | MVL+VL-immed | 0 | MVL+VL immed mode |
203 +-----------+-------------+--------------+----------+----------------------+
204 | 1 | VLdest | MVL-immed | 1 | MVL immed mode |
205 +-----------+-------------+--------------+----------+----------------------+
206
207 Note: when VLtyp is all zeros, neither VL nor MVL are changed.
208
209 Just as in the VLIW format, when bit 11 of VLtyp is zero:
210
211 * if vlt is zero, bits 1 to 5 specify the VLEN as a 5 bit immediate
212 (offset by 1: 0b00000 represents VL=1, 0b00001 represents VL=2 etc.)
213 * if vlt is 1, bits 1 to 5 specify the scalar (RV standard) register
214 from which VL is set. x0 is not permitted
215 * VL goes into the scalar register VLdest (if VLdest is not x0)
216
217 When bit 11 of VLtype is 1:
218
219 * if VLtyp[0] is zero, both MAXVL and VL are set to (imm+1). The same
220 value goes into the scalar register VLdest (if VLdest is not x0)
221 * if VLtyp[0] is 1, MAXVL is set to (imm+1).
222 VL will be truncated to within the new range (if VL was greater
223 than the new MAXVL). The new VL goes into the scalar register VLdest
224 (if VLdest is not x0).
225
226 This gives the option to set up VL in a "loop mode" (VLtype[11]=0) or
227 in a "one-off" mode (VLtype[11]=1) which sets both MVL and VL to the
228 same immediate value. This may be most useful for one-off Vectorised
229 operations such as LOAD-MULTI / STORE-MULTI, for saving and restoration
230 of large batches of registers in context-switches or function calls.
231
232 vs#/vd Fields' Encoding
233 =======================
234
235 +--------+----------+----------------------------------------------------------+
236 | vs#/vd | Mnemonic | Meaning |
237 +========+==========+==========================================================+
238 | 0 | S | the rs#/rd field specifies a scalar (single sub-vector); |
239 | | | the rs#/rd field is zero-extended to get the actual |
240 | | | 7-bit register number |
241 +--------+----------+----------------------------------------------------------+
242 | 1 | V | the rs#/rd field specifies a vector; the rs#/rd field is |
243 | | | decoded using the `Vector Register Number Encoding`_ to |
244 | | | get the actual 7-bit register number |
245 +--------+----------+----------------------------------------------------------+
246
247 If a vs#/vd field is not present, it is as if it was present with a value that
248 is the bitwise-or of all present vs#/vd fields.
249
250 * scalar register numbers do NOT increment when allocated in the
251 hardware for-loop. the same scalar register number is handed
252 to every ALU.
253
254 * vector register numbers *DO* increase when allocated in the
255 hardware for-loop. sequentially-increasing register data
256 is handed to sequential ALUs.
257
258 Vector Register Number Encoding
259 ===============================
260
261 For the 48 bit format, when vs#/vd is 1, the actual 7-bit register number is derived from the
262 corresponding 6-bit rs#/rd field:
263
264 +---------------------------------+
265 | Actual 7-bit register number |
266 +===========+=============+=======+
267 | Bit 6 | Bits 5:1 | Bit 0 |
268 +-----------+-------------+-------+
269 | rs#/rd[0] | rs#/rd[5:1] | 0 |
270 +-----------+-------------+-------+
271
272 For the 64 bit format, the 7 bit register is constructed from the 7 bit fields: bits 0 to 4 from the 32 bit RV Standard format, bit 5 from the 48 bit prefix and bit 6 from the 64 bit prefix. Thus in the 64 bit format the full range of up to 128 registers is directly available. This for both when either scalar or vector mode is set.
273
274 Load/Store Kind (lsk) Field Encoding
275 ====================================
276
277 +--------+-----+--------------------------------------------------------------------------------+
278 | vd/vs2 | vs1 | Meaning |
279 +========+=====+================================================================================+
280 | 0 | 0 | srcbase is scalar, LD/ST is pure scalar. |
281 +--------+-----+--------------------------------------------------------------------------------+
282 | 1 | 0 | srcbase is scalar, LD/ST is unit strided |
283 +--------+-----+--------------------------------------------------------------------------------+
284 | 0 | 1 | srcbase is a vector (gather/scatter aka array of srcbases). VSPLAT and VSELECT |
285 +--------+-----+--------------------------------------------------------------------------------+
286 | 1 | 1 | srcbase is a vector, LD/ST is a full vector LD/ST. |
287 +--------+-----+--------------------------------------------------------------------------------+
288
289 Notes:
290
291 * A register strided LD/ST would require *5* registers. srcbase, vd/vs2, predicate 1, predicate 2 and the stride register.
292 * Complex strides may all be done with a general purpose vector of srcbases.
293 * Twin predication may be used even when vd/vs1 is a scalar, to give VSPLAT and VSELECT, because the hardware loop ends on the first occurrence of a 1 in the predicate when a predicate is applied to a scalar.
294 * Full vectorised gather/scatter is enabled when both registers are marked as vectorised, however unlike e.g Intel AVX512, twin predication can be applied.
295
296 Open question: RVV overloads the width field of LOAD-FP/STORE-FP using the bit 2 to indicate additional interpretation of the 11 bit immediate. Should this be considered?
297
298
299 Sub-Vector Length (svlen) Field Encoding
300 =======================================================
301
302 Bitwidth, from VL's perspective, is a multiple of the elwidth times svlen. So within each loop of VL there are svlen sub-elements of elwidth in size, just like in a SIMD architecture. When svlen is set to 0b00 (indicating svlen=1) no such SIMD-like behaviour exists and the subvectoring is disabled.
303
304 Predicate bits do not apply to the individual sub-vector elements, they apply to the entire subvector group. This saves instructions on setup of the predicate.
305
306 +----------------+-------+
307 | svlen Encoding | Value |
308 +================+=======+
309 | 00 | 1 |
310 +----------------+-------+
311 | 01 | 2 |
312 +----------------+-------+
313 | 10 | 3 |
314 +----------------+-------+
315 | 11 | 4 |
316 +----------------+-------+
317
318 Setting of svtyp (when supported) will override SUBVL (when supported) solely for the duration of the 48/64 bit instruction.
319
320 Just as with the main VL loop, the sub-vector element instruction execution must appear to be in-order, and must be "re-entrant" (to use a software term).
321
322 Thus, if an exception occurs, SVPSTATE (**not STATE**) must store the current sub-element index, such that on return from the exception the instruction engine knows at which point in the sub-vector to continue execution.
323
324 If any sub-vector element execution was in progress at the point of the exception, those results **MUST** be discarded.
325
326 Also to reiterate: it is **critical** that STATE CSRs be unaltered and untouched by the use of svlen in a 48/64 bit opcode.
327
328 Predication (pred) Field Encoding
329 =================================
330
331 +------+------------+--------------------+----------------------------------------+
332 | pred | Mnemonic | Predicate Register | Meaning |
333 +======+============+====================+========================================+
334 | 000 | *None* | *None* | The instruction is unpredicated |
335 +------+------------+--------------------+----------------------------------------+
336 | 001 | *Reserved* | *Reserved* | |
337 +------+------------+--------------------+----------------------------------------+
338 | 010 | !x9 | x9 (s1) | execute vector op[0..i] on x9[i] == 0 |
339 +------+------------+ +----------------------------------------+
340 | 011 | x9 | | execute vector op[0..i] on x9[i] == 1 |
341 +------+------------+--------------------+----------------------------------------+
342 | 100 | !x10 | x10 (a0) | execute vector op[0..i] on x10[i] == 0 |
343 +------+------------+ +----------------------------------------+
344 | 101 | x10 | | execute vector op[0..i] on x10[i] == 1 |
345 +------+------------+--------------------+----------------------------------------+
346 | 110 | !x11 | x11 (a1) | execute vector op[0..i] on x11[i] == 0 |
347 +------+------------+ +----------------------------------------+
348 | 111 | x11 | | execute vector op[0..i] on x11[i] == 1 |
349 +------+------------+--------------------+----------------------------------------+
350
351 Twin-predication (tpred) Field Encoding
352 =======================================
353
354 +-------+------------+--------------------+----------------------------------------------+
355 | tpred | Mnemonic | Predicate Register | Meaning |
356 +=======+============+====================+==============================================+
357 | 000 | *None* | *None* | The instruction is unpredicated |
358 +-------+------------+--------------------+----------------------------------------------+
359 | 001 | x9,off | src=x9, dest=none | src[0..i] uses x9[i], dest unpredicated |
360 +-------+------------+ +----------------------------------------------+
361 | 010 | off,x10 | src=none, dest=x10 | dest[0..i] uses x10[i], src unpredicated |
362 +-------+------------+ +----------------------------------------------+
363 | 011 | x9,10 | src=x9, dest=x10 | src[0..i] uses x9[i], dest[0..i] uses x10[i] |
364 +-------+------------+--------------------+----------------------------------------------+
365 | 100 | *None* | *RESERVED* | Instruction is unpredicated (TBD) |
366 +-------+------------+--------------------+----------------------------------------------+
367 | 101 | !x9,off | src=!x9, dest=none | |
368 +-------+------------+ +----------------------------------------------+
369 | 110 | off,!x10 | src=none, dest=!x10| |
370 +-------+------------+ +----------------------------------------------+
371 | 111 | !x9,!x10 | src=!x9, dest=!x10 | |
372 +-------+------------+--------------------+----------------------------------------------+
373
374 Integer Element Type (itype) Field Encoding
375 ===========================================
376
377 +------------+-------+--------------+--------------+-----------------+-------------------+
378 | Signedness | itype | Element Type | Mnemonic in | Mnemonic in FP | Meaning (INT may |
379 | [#sgn_def]_| | | Integer | Instructions | be un/signed, FP |
380 | [#sgn_def]_| | | Instructions | (such as fmv.x) | just re-sized |
381 +============+=======+==============+==============+=================+===================+
382 | Unsigned | 01 | u8 | BU | BU | Unsigned 8-bit |
383 | +-------+--------------+--------------+-----------------+-------------------+
384 | | 10 | u16 | HU | HU | Unsigned 16-bit |
385 | +-------+--------------+--------------+-----------------+-------------------+
386 | | 11 | u32 | WU | WU | Unsigned 32-bit |
387 | +-------+--------------+--------------+-----------------+-------------------+
388 | | 00 | uXLEN | WU/DU/QU | WU/LU/TU | Unsigned XLEN-bit |
389 +------------+-------+--------------+--------------+-----------------+-------------------+
390 | Signed | 01 | i8 | BS | BS | Signed 8-bit |
391 | +-------+--------------+--------------+-----------------+-------------------+
392 | | 10 | i16 | HS | HS | Signed 16-bit |
393 | +-------+--------------+--------------+-----------------+-------------------+
394 | | 11 | i32 | W | W | Signed 32-bit |
395 | +-------+--------------+--------------+-----------------+-------------------+
396 | | 00 | iXLEN | W/D/Q | W/L/T | Signed XLEN-bit |
397 +------------+-------+--------------+--------------+-----------------+-------------------+
398
399 .. [#sgn_def] Signedness is defined in `Signedness Decision Procedure`_
400
401 Note: vector mode is effectively a type-cast of the register file
402 as if it was a sequential array being typecast to typedef itype[]
403 (c syntax). The starting point of the "typecast" is the vector
404 register rs#/rd.
405
406 Example: if itype=0b10 (u16), and rd is set to "vector", and
407 VL is set to 4, the 64-bit register at rd is subdivided into
408 *FOUR* 16-bit destination elements. It is *NOT* four
409 separate 64-bit destination registers (rd+0, rd+1, rd+2, rd+3)
410 that are sign-extended from the source width size out to 64-bit,
411 because that is itype=0b00 (uXLEN).
412
413 Note also: changing elwidth creates packed elements that, depending on VL, may create vectors that do not fit perfectly onto XLEM sized rehistry file boundaries. This does NOT result in the destruction of the MSBs of the last register written to at the end of a VL loop. More details on how to handle this are described in the main Specification_.
414
415 Signedness Decision Procedure
416 =============================
417
418 1. If the opcode field is either OP or OP-IMM, then
419 1. Signedness is Unsigned.
420 2. If the opcode field is either OP-32 or OP-IMM-32, then
421 1. Signedness is Signed.
422 3. If Signedness is encoded in a field of the base instruction, [#sign_enc]_ then
423 1. Signedness uses the encoded value.
424 4. Otherwise,
425 1. Signedness is Unsigned.
426
427 .. [#sign_enc] Like in fcvt.d.l[u], but unlike in fmv.x.w, since there is no
428 fmv.x.wu
429
430 Vector Type and Predication 5-bit (vtp5) Field Encoding
431 =======================================================
432
433 In the following table, X denotes a wildcard that is 0 or 1 and can be a
434 different value for every occurrence.
435
436 +-------+-----------+-----------+
437 | vtp5 | pred | svlen |
438 +=======+===========+===========+
439 | 1XXXX | vtp5[4:2] | vtp5[1:0] |
440 +-------+ | |
441 | 01XXX | | |
442 +-------+ | |
443 | 000XX | | |
444 +-------+-----------+-----------+
445 | 001XX | *Reserved* |
446 +-------+-----------------------+
447
448 Vector Integer Type and Predication 6-bit (vitp6) Field Encoding
449 ================================================================
450
451 In the following table, X denotes a wildcard that is 0 or 1 and can be a
452 different value for every occurrence.
453
454 +--------+------------+---------+------------+------------+
455 | vitp6 | itype | pred[2] | pred[0:1] | svlen |
456 +========+============+=========+============+============+
457 | XX1XXX | vitp6[5:4] | 0 | vitp6[3:2] | vitp6[1:0] |
458 +--------+ | | | |
459 | XX00XX | | | | |
460 +--------+------------+---------+------------+------------+
461 | XX01XX | *Reserved* |
462 +--------+------------------------------------------------+
463
464 vitp7 field: only tpred
465
466 +---------+------------+----------+-------------+------------+
467 | vitp7 | itype | tpred[2] | tpred[0:1] | svlen |
468 +=========+============+==========+=============+============+
469 | XXXXXXX | vitp7[5:4] | vitp7[6] | vitp7[3:2] | vitp7[1:0] |
470 +---------+------------+----------+-------------+------------+
471
472 48-bit Instruction Encoding Decision Procedure
473 ==============================================
474
475 In the following decision procedure, *Reserved* means that there is not yet a
476 defined 48-bit instruction encoding for the base instruction.
477
478 1. If the base instruction is a load instruction, then
479 a. If the base instruction is an I-type instruction, then
480 1. The encoding is P48-LD-type.
481 b. Otherwise
482 1. The encoding is *Reserved*.
483 2. If the base instruction is a store instruction, then
484 a. If the base instruction is an S-type instruction, then
485 1. The encoding is P48-ST-type.
486 b. Otherwise
487 1. The encoding is *Reserved*.
488 3. If the base instruction is a SYSTEM instruction, then
489 a. The encoding is *Reserved*.
490 4. If the base instruction is an integer instruction, then
491 a. If the base instruction is an R-type instruction, then
492 1. The encoding is P48-R-type.
493 b. If the base instruction is an I-type instruction, then
494 1. The encoding is P48-I-type.
495 c. If the base instruction is an S-type instruction, then
496 1. The encoding is *Reserved*.
497 d. If the base instruction is an B-type instruction, then
498 1. The encoding is *Reserved*.
499 e. If the base instruction is an U-type instruction, then
500 1. The encoding is P48-U-type.
501 f. If the base instruction is an J-type instruction, then
502 1. The encoding is *Reserved*.
503 g. Otherwise
504 1. The encoding is *Reserved*.
505 5. If the base instruction is a floating-point instruction, then
506 a. If the base instruction is an R-type instruction, then
507 1. The encoding is P48-FR-type.
508 b. If the base instruction is an I-type instruction, then
509 1. The encoding is P48-FI-type.
510 c. If the base instruction is an S-type instruction, then
511 1. The encoding is *Reserved*.
512 d. If the base instruction is an B-type instruction, then
513 1. The encoding is *Reserved*.
514 e. If the base instruction is an U-type instruction, then
515 1. The encoding is *Reserved*.
516 f. If the base instruction is an J-type instruction, then
517 1. The encoding is *Reserved*.
518 g. If the base instruction is an R4-type instruction, then
519 1. The encoding is P48-FR4-type.
520 h. Otherwise
521 1. The encoding is *Reserved*.
522 6. Otherwise
523 a. The encoding is *Reserved*.
524
525 CSR Registers
526 =============
527
528 CSRs are the same as in the main Specification_, if associated functionality is implemented. They have the exact same meaning as in the main specification.
529
530 * VL
531 * MVL
532 * STATE
533 * SUBVL
534
535 If svlen overrides are allowed in the 48 bit formats (and VLtyp usage likewise in the 64 bit format), the offsets during hardware loops need to be kept as internal state, and kept entirely separate from the same in the main Specification_. Therefore an additional CSR set is needed (per priv level) named xSVSTATE (x=u/s/h/m).
536
537 The format of the xSVSTATE CSR is identical to that in the main Specification_ as follows:
538
539 +---------+----------+----------+----------+----------+---------+---------+
540 | (30..29 | (28..27) | (26..24) | (23..18) | (17..12) | (11..6) | (5...0) |
541 +---------+----------+----------+----------+----------+---------+---------+
542 | dsvoffs | ssvoffs | subvl | destoffs | srcoffs | vl | maxvl |
543 +---------+----------+----------+----------+----------+---------+---------+
544
545 SetVL
546 =====
547
548 setvl rd, rs1, imm
549 setvl rd, rs1
550
551 This is done the same as Standard SV.
552 There is also a MVL CSR. CSRRW and CSRRWI operate in the same way as in SV. See Specification_.
553
554
555 Additional Instructions
556 =======================
557
558 Add instructions to convert between integer types.
559
560 Add instructions to `swizzle`_ elements in sub-vectors. Note that the sub-vector
561 lengths of the source and destination won't necessarily match.
562
563 .. _swizzle: https://www.khronos.org/opengl/wiki/Data_Type_(GLSL)#Swizzling
564
565 Add instructions to transpose (2-4)x(2-4) element matrices.
566
567 Add instructions to insert or extract a sub-vector from a vector, with the index
568 allowed to be both immediate and from a register (*immediate can be covered partly
569 by twin-predication, register cannot: requires MV.X aka VSELECT*)
570
571 Add a register gather instruction (aka MV.X)
572
573 # Open questions <a name="questions"></a>
574
575 Confirmation needed as to whether subvector extraction can be covered by twin predication (it probably can, it is one of the many purposes it is for).
576
577 --
578
579 What is SUBVL and how does it work
580
581 --
582
583 SVorig goes to a lot of effort to make VL 1<= MAXVL and MAXVL 1..64 where both CSRs may be stored internally in only 6 bits.
584
585 Thus, CSRRWI can reach 1..32 for VL and MAXVL.
586
587 In addition, setting a hardware loop to zero turning instructions into NOPs, um, just branch over them, to start the first loop at the end, on the test for loop variable being zero, a la c "while do" instead of "do while".
588
589 Or, does it not matter that VL only goes up to 31 on a CSRRWI, and that it only goes to a max of 63 rather than 64?
590
591 --
592
593 Should these questions be moved to Discussion subpage
594
595 --
596
597 Is MV.X good enough a substitute for swizzle?
598
599 --
600
601 Is vectorised srcbase ok as a gather scatter and ok substitute for register stride? 5 dependency registers (reg stride being the 5th) is quite scary
602
603 --
604
605 Why are integer conversion instructions needed, when the main SV spec covers them by allowing elwidth to be set on both src and dest regs?
606
607 --
608
609 Why are the SETVL rules so complex? What is the reason, how are loops carried out?
610
611 --
612
613 With SUBVL (sub vector len) being both a CSR and also part of the 48/64 bit opcode, how does that work?
614
615 --
616
617 What are the interaction rules when a 48/64 prefix opcode has a rd/rs that already has a Vector Context for either predication or a register?
618
619 It would perhaps make sense (and for svlen as well) to make 48/64 isolated and unaffected by VLIW context, with the exception of VL/MVL.
620
621 MVL and VL should be modifiable by 64 bit prefix as they are global in nature.
622