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