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