1 # Variable-width Variable-packed SIMD / Simple-V / Parallelism Extension Proposal
3 * TODO 23may2018: CSR-CAM-ify regfile tables
4 * TODO 23may2018: zero-mark predication CSR
5 * TODO 28may2018: sort out VSETVL: CSR length to be removed?
6 * TODO 09jun2018: Chennai Presentation more up-to-date
7 * TODO 09jun2019: elwidth only 4 values (dflt, dflt/2, 8, 16)
8 * TODO 09jun2019: extra register banks (future option)
9 * TODO 09jun2019: new Reg CSR table (incl. packed=Y/N)
12 Key insight: Simple-V is intended as an abstraction layer to provide
13 a consistent "API" to parallelisation of existing *and future* operations.
14 *Actual* internal hardware-level parallelism is *not* required, such
15 that Simple-V may be viewed as providing a "compact" or "consolidated"
16 means of issuing multiple near-identical arithmetic instructions to an
17 instruction queue (FIFO), pending execution.
19 *Actual* parallelism, if added independently of Simple-V in the form
20 of Out-of-order restructuring (including parallel ALU lanes) or VLIW
21 implementations, or SIMD, or anything else, would then benefit from
22 the uniformity of a consistent API.
28 This proposal exists so as to be able to satisfy several disparate
29 requirements: power-conscious, area-conscious, and performance-conscious
30 designs all pull an ISA and its implementation in different conflicting
31 directions, as do the specific intended uses for any given implementation.
33 The existing P (SIMD) proposal and the V (Vector) proposals,
34 whilst each extremely powerful in their own right and clearly desirable,
37 * Clearly independent in their origins (Cray and AndesStar v3 respectively)
38 so need work to adapt to the RISC-V ethos and paradigm
39 * Are sufficiently large so as to make adoption (and exploration for
40 analysis and review purposes) prohibitively expensive
41 * Both contain partial duplication of pre-existing RISC-V instructions
42 (an undesirable characteristic)
43 * Both have independent, incompatible and disparate methods for introducing
44 parallelism at the instruction level
45 * Both require that their respective parallelism paradigm be implemented
46 along-side and integral to their respective functionality *or not at all*.
47 * Both independently have methods for introducing parallelism that
48 could, if separated, benefit
49 *other areas of RISC-V not just DSP or Floating-point respectively*.
51 There are also key differences between Vectorisation and SIMD (full
52 details outlined in the Appendix), the key points being:
54 * SIMD has an extremely seductively compelling ease of implementation argument:
55 each operation is passed to the ALU, which is where the parallelism
56 lies. There is *negligeable* (if any) impact on the rest of the core
57 (with life instead being made hell for compiler writers and applications
58 writers due to extreme ISA proliferation).
59 * By contrast, Vectorisation has quite some complexity (for considerable
60 flexibility, reduction in opcode proliferation and much more).
61 * Vectorisation typically includes much more comprehensive memory load
62 and store schemes (unit stride, constant-stride and indexed), which
63 in turn have ramifications: virtual memory misses (TLB cache misses)
64 and even multiple page-faults... all caused by a *single instruction*,
65 yet with a clear benefit that the regularisation of LOAD/STOREs can
66 be optimised for minimal impact on caches and maximised throughput.
67 * By contrast, SIMD can use "standard" memory load/stores (32-bit aligned
68 to pages), and these load/stores have absolutely nothing to do with the
69 SIMD / ALU engine, no matter how wide the operand. Simplicity but with
70 more impact on instruction and data caches.
72 Overall it makes a huge amount of sense to have a means and method
73 of introducing instruction parallelism in a flexible way that provides
74 implementors with the option to choose exactly where they wish to offer
75 performance improvements and where they wish to optimise for power
76 and/or area (and if that can be offered even on a per-operation basis that
77 would provide even more flexibility).
79 Additionally it makes sense to *split out* the parallelism inherent within
80 each of P and V, and to see if each of P and V then, in *combination* with
81 a "best-of-both" parallelism extension, could be added on *on top* of
82 this proposal, to topologically provide the exact same functionality of
83 each of P and V. Each of P and V then can focus on providing the best
84 operations possible for their respective target areas, without being
85 hugely concerned about the actual parallelism.
87 Furthermore, an additional goal of this proposal is to reduce the number
88 of opcodes utilised by each of P and V as they currently stand, leveraging
89 existing RISC-V opcodes where possible, and also potentially allowing
90 P and V to make use of Compressed Instructions as a result.
92 # Analysis and discussion of Vector vs SIMD
94 There are six combined areas between the two proposals that help with
95 parallelism (increased performance, reduced power / area) without
96 over-burdening the ISA with a huge proliferation of
99 * Fixed vs variable parallelism (fixed or variable "M" in SIMD)
100 * Implicit vs fixed instruction bit-width (integral to instruction or not)
101 * Implicit vs explicit type-conversion (compounded on bit-width)
102 * Implicit vs explicit inner loops.
103 * Single-instruction LOAD/STORE.
104 * Masks / tagging (selecting/preventing certain indexed elements from execution)
106 The pros and cons of each are discussed and analysed below.
108 ## Fixed vs variable parallelism length
110 In David Patterson and Andrew Waterman's analysis of SIMD and Vector
111 ISAs, the analysis comes out clearly in favour of (effectively) variable
112 length SIMD. As SIMD is a fixed width, typically 4, 8 or in extreme cases
113 16 or 32 simultaneous operations, the setup, teardown and corner-cases of SIMD
114 are extremely burdensome except for applications whose requirements
115 *specifically* match the *precise and exact* depth of the SIMD engine.
117 Thus, SIMD, no matter what width is chosen, is never going to be acceptable
118 for general-purpose computation, and in the context of developing a
119 general-purpose ISA, is never going to satisfy 100 percent of implementors.
121 To explain this further: for increased workloads over time, as the
122 performance requirements increase for new target markets, implementors
123 choose to extend the SIMD width (so as to again avoid mixing parallelism
124 into the instruction issue phases: the primary "simplicity" benefit of
125 SIMD in the first place), with the result that the entire opcode space
126 effectively doubles with each new SIMD width that's added to the ISA.
128 That basically leaves "variable-length vector" as the clear *general-purpose*
129 winner, at least in terms of greatly simplifying the instruction set,
130 reducing the number of instructions required for any given task, and thus
131 reducing power consumption for the same.
133 ## Implicit vs fixed instruction bit-width
135 SIMD again has a severe disadvantage here, over Vector: huge proliferation
136 of specialist instructions that target 8-bit, 16-bit, 32-bit, 64-bit, and
137 have to then have operations *for each and between each*. It gets very
138 messy, very quickly: *six* separate dimensions giving an O(N^6) instruction
139 proliferation profile.
141 The V-Extension on the other hand proposes to set the bit-width of
142 future instructions on a per-register basis, such that subsequent instructions
143 involving that register are *implicitly* of that particular bit-width until
144 otherwise changed or reset.
146 This has some extremely useful properties, without being particularly
147 burdensome to implementations, given that instruction decode already has
148 to direct the operation to a correctly-sized width ALU engine, anyway.
150 Not least: in places where an ISA was previously constrained (due for
151 whatever reason, including limitations of the available operand space),
152 implicit bit-width allows the meaning of certain operations to be
153 type-overloaded *without* pollution or alteration of frozen and immutable
154 instructions, in a fully backwards-compatible fashion.
156 ## Implicit and explicit type-conversion
158 The Draft 2.3 V-extension proposal has (deprecated) polymorphism to help
159 deal with over-population of instructions, such that type-casting from
160 integer (and floating point) of various sizes is automatically inferred
161 due to "type tagging" that is set with a special instruction. A register
162 will be *specifically* marked as "16-bit Floating-Point" and, if added
163 to an operand that is specifically tagged as "32-bit Integer" an implicit
164 type-conversion will take place *without* requiring that type-conversion
165 to be explicitly done with its own separate instruction.
167 However, implicit type-conversion is not only quite burdensome to
168 implement (explosion of inferred type-to-type conversion) but also is
169 never really going to be complete. It gets even worse when bit-widths
170 also have to be taken into consideration. Each new type results in
171 an increased O(N^2) conversion space that, as anyone who has examined
172 python's source code (which has built-in polymorphic type-conversion),
173 knows that the task is more complex than it first seems.
175 Overall, type-conversion is generally best to leave to explicit
176 type-conversion instructions, or in definite specific use-cases left to
177 be part of an actual instruction (DSP or FP)
179 ## Zero-overhead loops vs explicit loops
181 The initial Draft P-SIMD Proposal by Chuanhua Chang of Andes Technology
182 contains an extremely interesting feature: zero-overhead loops. This
183 proposal would basically allow an inner loop of instructions to be
184 repeated indefinitely, a fixed number of times.
186 Its specific advantage over explicit loops is that the pipeline in a DSP
187 can potentially be kept completely full *even in an in-order single-issue
188 implementation*. Normally, it requires a superscalar architecture and
189 out-of-order execution capabilities to "pre-process" instructions in
190 order to keep ALU pipelines 100% occupied.
192 By bringing that capability in, this proposal could offer a way to increase
193 pipeline activity even in simpler implementations in the one key area
194 which really matters: the inner loop.
196 However when looking at much more comprehensive schemes
197 "A portable specification of zero-overhead loop control hardware
198 applied to embedded processors" (ZOLC), optimising only the single
199 inner loop seems inadequate, tending to suggest that ZOLC may be
200 better off being proposed as an entirely separate Extension.
202 ## Single-instruction LOAD/STORE
204 In traditional Vector Architectures there are instructions which
205 result in multiple register-memory transfer operations resulting
206 from a single instruction. They're complicated to implement in hardware,
207 yet the benefits are a huge consistent regularisation of memory accesses
208 that can be highly optimised with respect to both actual memory and any
209 L1, L2 or other caches. In Hwacha EECS-2015-263 it is explicitly made
210 clear the consequences of getting this architecturally wrong:
211 L2 cache-thrashing at the very least.
213 Complications arise when Virtual Memory is involved: TLB cache misses
214 need to be dealt with, as do page faults. Some of the tradeoffs are
215 discussed in <http://people.eecs.berkeley.edu/~krste/thesis.pdf>, Section
216 4.6, and an article by Jeff Bush when faced with some of these issues
217 is particularly enlightening
218 <https://jbush001.github.io/2015/11/03/lost-in-translation.html>
220 Interestingly, none of this complexity is faced in SIMD architectures...
221 but then they do not get the opportunity to optimise for highly-streamlined
222 memory accesses either.
224 With the "bang-per-buck" ratio being so high and the indirect improvement
225 in L1 Instruction Cache usage (reduced instruction count), as well as
226 the opportunity to optimise L1 and L2 cache usage, the case for including
227 Vector LOAD/STORE is compelling.
229 ## Mask and Tagging (Predication)
231 Tagging (aka Masks aka Predication) is a pseudo-method of implementing
232 simplistic branching in a parallel fashion, by allowing execution on
233 elements of a vector to be switched on or off depending on the results
234 of prior operations in the same array position.
236 The reason for considering this is simple: by *definition* it
237 is not possible to perform individual parallel branches in a SIMD
238 (Single-Instruction, **Multiple**-Data) context. Branches (modifying
239 of the Program Counter) will result in *all* parallel data having
240 a different instruction executed on it: that's just the definition of
241 SIMD, and it is simply unavoidable.
243 So these are the ways in which conditional execution may be implemented:
245 * explicit compare and branch: BNE x, y -> offs would jump offs
246 instructions if x was not equal to y
247 * explicit store of tag condition: CMP x, y -> tagbit
248 * implicit (condition-code) such as ADD results in a carry, carry bit
249 implicitly (or sometimes explicitly) goes into a "tag" (mask) register
251 The first of these is a "normal" branch method, which is flat-out impossible
252 to parallelise without look-ahead and effectively rewriting instructions.
253 This would defeat the purpose of RISC.
255 The latter two are where parallelism becomes easy to do without complexity:
256 every operation is modified to be "conditionally executed" (in an explicit
257 way directly in the instruction format *or* implicitly).
259 RVV (Vector-Extension) proposes to have *explicit* storing of the compare
260 in a tag/mask register, and to *explicitly* have every vector operation
261 *require* that its operation be "predicated" on the bits within an
262 explicitly-named tag/mask register.
264 SIMD (P-Extension) has not yet published precise documentation on what its
265 schema is to be: there is however verbal indication at the time of writing
268 > The "compare" instructions in the DSP/SIMD ISA proposed by Andes will
269 > be executed using the same compare ALU logic for the base ISA with some
270 > minor modifications to handle smaller data types. The function will not
273 This is an *implicit* form of predication as the base RV ISA does not have
274 condition-codes or predication. By adding a CSR it becomes possible
275 to also tag certain registers as "predicated if referenced as a destination".
278 // in future operations from now on, if r0 is the destination use r5 as
279 // the PREDICATION register
280 SET_IMPLICIT_CSRPREDICATE r0, r5
281 // store the compares in r5 as the PREDICATION register
283 // r0 is used here. ah ha! that means it's predicated using r5!
286 With enough registers (and in RISC-V there are enough registers) some fairly
287 complex predication can be set up and yet still execute without significant
288 stalling, even in a simple non-superscalar architecture.
290 (For details on how Branch Instructions would be retro-fitted to indirectly
291 predicated equivalents, see Appendix)
295 In the above sections the five different ways where parallel instruction
296 execution has closely and loosely inter-related implications for the ISA and
297 for implementors, were outlined. The pluses and minuses came out as
300 * Fixed vs variable parallelism: <b>variable</b>
301 * Implicit (indirect) vs fixed (integral) instruction bit-width: <b>indirect</b>
302 * Implicit vs explicit type-conversion: <b>explicit</b>
303 * Implicit vs explicit inner loops: <b>implicit but best done separately</b>
304 * Single-instruction Vector LOAD/STORE: <b>Complex but highly beneficial</b>
305 * Tag or no-tag: <b>Complex but highly beneficial</b>
309 * variable-length vectors came out on top because of the high setup, teardown
310 and corner-cases associated with the fixed width of SIMD.
311 * Implicit bit-width helps to extend the ISA to escape from
312 former limitations and restrictions (in a backwards-compatible fashion),
313 whilst also leaving implementors free to simmplify implementations
314 by using actual explicit internal parallelism.
315 * Implicit (zero-overhead) loops provide a means to keep pipelines
316 potentially 100% occupied in a single-issue in-order implementation
317 i.e. *without* requiring a super-scalar or out-of-order architecture,
318 but doing a proper, full job (ZOLC) is an entirely different matter.
320 Constructing a SIMD/Simple-Vector proposal based around four of these six
321 requirements would therefore seem to be a logical thing to do.
323 # Note on implementation of parallelism
325 One extremely important aspect of this proposal is to respect and support
326 implementors desire to focus on power, area or performance. In that regard,
327 it is proposed that implementors be free to choose whether to implement
328 the Vector (or variable-width SIMD) parallelism as sequential operations
329 with a single ALU, fully parallel (if practical) with multiple ALUs, or
330 a hybrid combination of both.
332 In Broadcom's Videocore-IV, they chose hybrid, and called it "Virtual
333 Parallelism". They achieve a 16-way SIMD at an **instruction** level
334 by providing a combination of a 4-way parallel ALU *and* an externally
335 transparent loop that feeds 4 sequential sets of data into each of the
338 Also in the same core, it is worth noting that particularly uncommon
339 but essential operations (Reciprocal-Square-Root for example) are
340 *not* part of the 4-way parallel ALU but instead have a *single* ALU.
341 Under the proposed Vector (varible-width SIMD) implementors would
342 be free to do precisely that: i.e. free to choose *on a per operation
343 basis* whether and how much "Virtual Parallelism" to deploy.
345 It is absolutely critical to note that it is proposed that such choices MUST
346 be **entirely transparent** to the end-user and the compiler. Whilst
347 a Vector (varible-width SIMD) may not precisely match the width of the
348 parallelism within the implementation, the end-user **should not care**
349 and in this way the performance benefits are gained but the ISA remains
350 straightforward. All that happens at the end of an instruction run is: some
351 parallel units (if there are any) would remain offline, completely
352 transparently to the ISA, the program, and the compiler.
354 To make that clear: should an implementor choose a particularly wide
355 SIMD-style ALU, each parallel unit *must* have predication so that
356 the parallel SIMD ALU may emulate variable-length parallel operations.
357 Thus the "SIMD considered harmful" trap of having huge complexity and extra
358 instructions to deal with corner-cases is thus avoided, and implementors
359 get to choose precisely where to focus and target the benefits of their
360 implementation efforts, without "extra baggage".
362 In addition, implementors will be free to choose whether to provide an
363 absolute bare minimum level of compliance with the "API" (software-traps
364 when vectorisation is detected), all the way up to full supercomputing
365 level all-hardware parallelism. Options are covered in the Appendix.
367 # CSRs <a name="csrs"></a>
369 There are two CSR tables needed to create lookup tables which are used at
370 the register decode phase.
372 * Integer Register N is Vector
373 * Integer Register N is of implicit bitwidth M (M=default,8,16,32,64)
374 * Floating-point Register N is Vector of length M: r(N) -> r(N..N+M-1)
375 * Floating-point Register N is of implicit bitwidth M (M=default,8,16,32,64)
376 * Integer Register N is a Predication Register (note: a key-value store)
378 Also (see Appendix, "Context Switch Example") it may turn out to be important
379 to have a separate (smaller) set of CSRs for M-Mode (and S-Mode) so that
380 Vectorised LOAD / STORE may be used to load and store multiple registers:
381 something that is missing from the Base RV ISA.
385 * for the purposes of LOAD / STORE, Integer Registers which are
386 marked as a Vector will result in a Vector LOAD / STORE.
387 * Vector Lengths are *not* the same as vsetl but are an integral part
389 * Actual vector length is *multipled* by how many blocks of length
390 "bitwidth" may fit into an XLEN-sized register file.
391 * Predication is a key-value store due to the implicit referencing,
392 as opposed to having the predicate register explicitly in the instruction.
393 * Whilst the predication CSR is a key-value store it *generates* easier-to-use
395 * TODO: assess whether the same technique could be applied to the other
396 Vector CSRs, particularly as pointed out in Section 17.8 (Draft RV 0.4,
397 V2.3-Draft ISA Reference) it becomes possible to greatly reduce state
398 needed for context-switches (empty slots need never be stored).
400 ## Predication CSR <a name="predication_csr_table"></a>
402 The Predication CSR is a key-value store indicating whether, if a given
403 destination register (integer or floating-point) is referred to in an
404 instruction, it is to be predicated. However it is important to note
405 that the *actual* register is *different* from the one that ends up
406 being used, due to the level of indirection through the lookup table.
407 This includes (in the future) redirecting to a *second* bank of
408 integer registers (as a future option)
410 * regidx is the actual register that in combination with the
411 i/f flag, if that integer or floating-point register is referred to,
412 results in the lookup table being referenced to find the predication
413 mask to use on the operation in which that (regidx) register has
415 * predidx (in combination with the bank bit in the future) is the
416 *actual* register to be used for the predication mask. Note:
417 in effect predidx is actually a 6-bit register address, as the bank
418 bit is the MSB (and is nominally set to zero for now).
419 * inv indicates that the predication mask bits are to be inverted
420 prior to use *without* actually modifying the contents of the
422 * zeroing is either 1 or 0, and if set to 1, the operation must
423 place zeros in any element position where the predication mask is
424 set to zero. If zeroing is set to 1, unpredicated elements *must*
425 be left alone. Some microarchitectures may choose to interpret
426 this as skipping the operation entirely. Others which wish to
427 stick more closely to a SIMD architecture may choose instead to
428 interpret unpredicated elements as an internal "copy element"
429 operation (which would be necessary in SIMD microarchitectures
430 that perform register-renaming)
432 | PrCSR | 13 | 12 | 11 | 10 | (9..5) | (4..0) |
433 | ----- | - | - | - | - | ------- | ------- |
434 | 0 | bank0 | zero0 | inv0 | i/f | regidx | predidx |
435 | 1 | bank1 | zero1 | inv1 | i/f | regidx | predidx |
436 | .. | bank.. | zero.. | inv.. | i/f | regidx | predidx |
437 | 15 | bank15 | zero15 | inv15 | i/f | regidx | predidx |
439 The Predication CSR Table is a key-value store, so implementation-wise
440 it will be faster to turn the table around (maintain topologically
446 bool bank; // 0 for now, 1=rsvd
448 int predidx; // redirection: actual int register to use
451 struct pred fp_pred_reg[32]; // 64 in future (bank=1)
452 struct pred int_pred_reg[32]; // 64 in future (bank=1)
454 for (i = 0; i < 16; i++)
455 tb = int_pred_reg if CSRpred[i].type == 0 else fp_pred_reg;
456 idx = CSRpred[i].regidx
457 tb[idx].zero = CSRpred[i].zero
458 tb[idx].inv = CSRpred[i].inv
459 tb[idx].bank = CSRpred[i].bank
460 tb[idx].predidx = CSRpred[i].predidx
461 tb[idx].enabled = true
463 So when an operation is to be predicated, it is the internal state that
464 is used. In Section 6.4.2 of Hwacha's Manual (EECS-2015-262) the following
465 pseudo-code for operations is given, where p is the explicit (direct)
466 reference to the predication register to be used:
468 for (int i=0; i<vl; ++i)
470 (d ? vreg[rd][i] : sreg[rd]) =
471 iop(s1 ? vreg[rs1][i] : sreg[rs1],
472 s2 ? vreg[rs2][i] : sreg[rs2]); // for insts with 2 inputs
474 This instead becomes an *indirect* reference using the *internal* state
475 table generated from the Predication CSR key-value store, which iwws used
479 preg = int_pred_reg[rd]
481 preg = fp_pred_reg[rd]
483 for (int i=0; i<vl; ++i)
484 predidx = preg[rd].predidx; // the indirection takes place HERE
485 if (!preg[rd].enabled)
486 predicate = ~0x0; // all parallel ops enabled
488 predicate = intregfile[predidx]; // get actual reg contents HERE
489 if (preg[rd].inv) // invert if requested
490 predicate = ~predicate;
491 if (predicate && (1<<i))
492 (d ? regfile[rd+i] : regfile[rd]) =
493 iop(s1 ? regfile[rs1+i] : regfile[rs1],
494 s2 ? regfile[rs2+i] : regfile[rs2]); // for insts with 2 inputs
495 else if (preg[rd].zero)
496 // TODO: place zero in dest reg
500 * d, s1 and s2 are booleans indicating whether destination,
501 source1 and source2 are vector or scalar
502 * key-value CSR-redirection of rd, rs1 and rs2 have NOT been included
503 above, for clarity. rd, rs1 and rs2 all also must ALSO go through
504 register-level redirection (from the Register CSR table) if they are
507 If written as a function, obtaining the predication mask (but not whether
508 zeroing takes place) may be done as follows:
510 def get_pred_val(bool is_fp_op, int reg):
511 tb = int_pred if is_fp_op else fp_pred
512 if (!tb[reg].enabled):
513 return ~0x0 // all ops enabled
514 predidx = tb[reg].predidx // redirection occurs HERE
515 predicate = intreg[predidx] // actual predicate HERE
517 predicate = ~predicate // invert ALL bits
522 MAXVECTORLENGTH is the same concept as MVL in RVV. However in Simple-V,
523 given that its primary (base, unextended) purpose is for 3D, Video and
524 other purposes (not requiring supercomputing capability), it makes sense
525 to limit MAXVECTORDEPTH to the regfile bitwidth (32 for RV32, 64 for RV64
528 The reason for setting this limit is so that predication registers, when
529 marked as such, may fit into a single register as opposed to fanning out
530 over several registers. This keeps the implementation a little simpler.
531 Note also (as also described in the VSETVL section) that the *minimum*
532 for MAXVECTORDEPTH must be the total number of registers (15 for RV32E
533 and 31 for RV32 or RV64).
535 Note that RVV on top of Simple-V may choose to over-ride this decision.
537 ## Register CSR key-value (CAM) table
539 The purpose of the Register CSR table is four-fold:
541 * To mark integer and floating-point registers as requiring "redirection"
542 if it is ever used as a source or destination in any given operation.
543 This involves a level of indirection through a 5-to-6-bit lookup table
544 (where the 6th bit - bank - is always set to 0 for now).
545 * To indicate whether, after redirection through the lookup table, the
546 register is a vector (or remains a scalar).
547 * To over-ride the implicit or explicit bitwidth that the operation would
548 normally give the register.
549 * To indicate if the register is to be interpreted as "packed" (SIMD)
550 i.e. containing multiple contiguous elements of size equal to "bitwidth".
552 | RgCSR | 15 | 14 | 13 | (12..11) | 10 | (9..5) | (4..0) |
553 | ----- | - | - | - | - | - | ------- | ------- |
554 | 0 | simd0 | bank0 | isvec0 | vew0 | i/f | regidx | predidx |
555 | 1 | simd1 | bank1 | isvec1 | vew1 | i/f | regidx | predidx |
556 | .. | simd.. | bank.. | isvec.. | vew.. | i/f | regidx | predidx |
557 | 15 | simd15 | bank15 | isvec15 | vew15 | i/f | regidx | predidx |
559 vew may be one of the following (giving a table "bytestable", used below):
568 Extending this table (with extra bits) is covered in the section
569 "Implementing RVV on top of Simple-V".
571 As the above table is a CAM (key-value store) it may be appropriate
572 to expand it as follows:
574 struct vectorised fp_vec[32], int_vec[32]; // 64 in future
576 for (i = 0; i < 16; i++) // 16 CSRs?
577 tb = int_vec if CSRvec[i].type == 0 else fp_vec
578 idx = CSRvec[i].regkey // INT/FP src/dst reg in opcode
579 tb[idx].elwidth = CSRvec[i].elwidth
580 tb[idx].regidx = CSRvec[i].regidx // indirection
581 tb[idx].isvector = CSRvec[i].isvector // 0=scalar
582 tb[idx].packed = CSRvec[i].packed // SIMD or not
583 tb[idx].bank = CSRvec[i].bank // 0 (1=rsvd)
587 # TODO: use elsewhere (retire for now)
588 vew = CSRbitwidth[rs1]
590 bytesperreg = (XLEN/8) # or FLEN as appropriate
592 bytesperreg = (XLEN/4) # or FLEN/2 as appropriate
594 bytesperreg = bytestable[vew] # 8 or 16
595 simdmult = (XLEN/8) / bytesperreg # or FLEN as appropriate
596 vlen = CSRvectorlen[rs1] * simdmult
597 CSRvlength = MIN(MIN(vlen, MAXVECTORDEPTH), rs2)
599 The reason for multiplying the vector length by the number of SIMD elements
600 (in each individual register) is so that each SIMD element may optionally be
603 An example of how to subdivide the register file when bitwidth != default
604 is given in the section "Bitwidth Virtual Register Reordering".
608 Despite being a 98% complete and accurate topological remap of RVV
609 concepts and functionality, the only instructions needed are VSETVL
610 and VGETVL. *All* RVV instructions can be re-mapped, however xBitManip
611 becomes a critical dependency for efficient manipulation of predication
612 masks (as a bit-field). Despite the removal of all but VSETVL and VGETVL,
613 *all instructions from RVV are topologically re-mapped and retain their
614 complete functionality, intact*.
616 Three instructions, VSELECT, VCLIP and VCLIPI, do not have RV Standard
617 equivalents, so are left out of Simple-V. VSELECT could be included if
618 there existed a MV.X instruction in RV (MV.X is a hypothetical
619 non-immediate variant of MV that would allow another register to
620 specify which register was to be copied). Note that if any of these three
621 instructions are added to any given RV extension, their functionality
622 will be inherently parallelised.
624 ## Instruction Format
626 The instruction format for Simple-V does not actually have *any* explicit
627 compare operations, *any* arithmetic, floating point or *any*
629 Instead it *overloads* pre-existing branch operations into predicated
630 variants, and implicitly overloads arithmetic operations, MV,
632 depending on CSR configurations for bitwidth and
633 predication. **Everything** becomes parallelised. *This includes
634 Compressed instructions* as well as any
635 future instructions and Custom Extensions.
637 * For analysis of RVV see [[v_comparative_analysis]] which begins to
638 outline topologically-equivalent mappings of instructions
639 * Also see Appendix "Retro-fitting Predication into branch-explicit ISA"
640 for format of Branch opcodes.
642 **TODO**: *analyse and decide whether the implicit nature of predication
643 as proposed is or is not a lot of hassle, and if explicit prefixes are
644 a better idea instead. Parallelism therefore effectively may end up
645 as always being 64-bit opcodes (32 for the prefix, 32 for the instruction)
646 with some opportunities for to use Compressed bringing it down to 48.
647 Also to consider is whether one or both of the last two remaining Compressed
648 instruction codes in Quadrant 1 could be used as a parallelism prefix,
649 bringing parallelised opcodes down to 32-bit (when combined with C)
650 and having the benefit of being explicit.*
654 NOTE TODO: 28may2018: VSETVL may need to be *really* different from RVV,
655 with the instruction format remaining the same.
657 VSETVL is slightly different from RVV in that the minimum vector length
658 is required to be at least the number of registers in the register file,
659 and no more than XLEN. This allows vector LOAD/STORE to be used to switch
660 the entire bank of registers using a single instruction (see Appendix,
661 "Context Switch Example"). The reason for limiting VSETVL to XLEN is
662 down to the fact that predication bits fit into a single register of length
665 The second change is that when VSETVL is requested to be stored
666 into x0, it is *ignored* silently (VSETVL x0, x5, #4)
668 The third change is that there is an additional immediate added to VSETVL,
669 to which VL is set after first going through MIN-filtering.
670 So When using the "vsetl rs1, rs2, #vlen" instruction, it becomes:
672 VL = MIN(MIN(vlen, MAXVECTORDEPTH), rs2)
674 where RegfileLen <= MAXVECTORDEPTH < XLEN
676 This has implication for the microarchitecture, as VL is required to be
677 set (limits from MAXVECTORDEPTH notwithstanding) to the actual value
678 requested in the #immediate parameter. RVV has the option to set VL
679 to an arbitrary value that suits the conditions and the micro-architecture:
680 SV does *not* permit that.
682 The reason is so that if SV is to be used for a context-switch or as a
683 substitute for LOAD/STORE-Multiple, the operation can be done with only
684 2-3 instructions (setup of the CSRs, VSETVL x0, x0, #{regfilelen-1},
685 single LD/ST operation). If VL does *not* get set to the register file
686 length when VSETVL is called, then a software-loop would be needed.
687 To avoid this need, VL *must* be set to exactly what is requested
688 (limits notwithstanding).
690 Therefore, in turn, unlike RVV, implementors *must* provide
691 pseudo-parallelism (using sequential loops in hardware) if actual
692 hardware-parallelism in the ALUs is not deployed. A hybrid is also
693 permitted (as used in Broadcom's VideoCore-IV) however this must be
694 *entirely* transparent to the ISA.
696 ## Branch Instruction:
698 Branch operations use standard RV opcodes that are reinterpreted to
699 be "predicate variants" in the instance where either of the two src
700 registers are marked as vectors (isvector=1). When this reinterpretation
701 is enabled the "immediate" field of the branch operation is taken to be a
702 predication target register, rs3. The predicate target register rs3 is
703 to be treated as a bitfield (up to a maximum of XLEN bits corresponding
704 to a maximum of XLEN elements).
706 If either of src1 or src2 are scalars (CSRvectorlen[src] == 0) the comparison
707 goes ahead as vector-scalar or scalar-vector. Implementors should note that
708 this could require considerable multi-porting of the register file in order
709 to parallelise properly, so may have to involve the use of register cacheing
710 and transparent copying (see Multiple-Banked Register File Architectures
713 In instances where no vectorisation is detected on either src registers
714 the operation is treated as an absolutely standard scalar branch operation.
716 This is the overloaded table for Integer-base Branch operations. Opcode
717 (bits 6..0) is set in all cases to 1100011.
720 31 .. 25 |24 ... 20 | 19 15 | 14 12 | 11 .. 8 | 7 | 6 ... 0 |
721 imm[12,10:5]| rs2 | rs1 | funct3 | imm[4:1] | imm[11] | opcode |
722 7 | 5 | 5 | 3 | 4 | 1 | 7 |
723 reserved | src2 | src1 | BPR | predicate rs3 || BRANCH |
724 reserved | src2 | src1 | 000 | predicate rs3 || BEQ |
725 reserved | src2 | src1 | 001 | predicate rs3 || BNE |
726 reserved | src2 | src1 | 010 | predicate rs3 || rsvd |
727 reserved | src2 | src1 | 011 | predicate rs3 || rsvd |
728 reserved | src2 | src1 | 100 | predicate rs3 || BLE |
729 reserved | src2 | src1 | 101 | predicate rs3 || BGE |
730 reserved | src2 | src1 | 110 | predicate rs3 || BLTU |
731 reserved | src2 | src1 | 111 | predicate rs3 || BGEU |
734 Note that just as with the standard (scalar, non-predicated) branch
735 operations, BLT, BGT, BLEU and BTGU may be synthesised by inverting
738 Below is the overloaded table for Floating-point Predication operations.
739 Interestingly no change is needed to the instruction format because
740 FP Compare already stores a 1 or a zero in its "rd" integer register
741 target, i.e. it's not actually a Branch at all: it's a compare.
742 The target needs to simply change to be a predication bitfield (done
746 Standard RVF/D/Q, Opcode (bits 6..0) is set in all cases to 1010011.
747 Likewise Single-precision, fmt bits 26..25) is still set to 00.
748 Double-precision is still set to 01, whilst Quad-precision
749 appears not to have a definition in V2.3-Draft (but should be unaffected).
751 It is however noted that an entry "FNE" (the opposite of FEQ) is missing,
752 and whilst in ordinary branch code this is fine because the standard
753 RVF compare can always be followed up with an integer BEQ or a BNE (or
754 a compressed comparison to zero or non-zero), in predication terms that
755 becomes more of an impact. To deal with this, SV's predication has
756 had "invert" added to it.
759 31 .. 27| 26 .. 25 |24 ... 20 | 19 15 | 14 12 | 11 .. 7 | 6 ... 0 |
760 funct5 | fmt | rs2 | rs1 | funct3 | rd | opcode |
761 5 | 2 | 5 | 5 | 3 | 4 | 7 |
762 10100 | 00/01/11 | src2 | src1 | 010 | pred rs3 | FEQ |
763 10100 | 00/01/11 | src2 | src1 | **011**| pred rs3 | rsvd |
764 10100 | 00/01/11 | src2 | src1 | 001 | pred rs3 | FLT |
765 10100 | 00/01/11 | src2 | src1 | 000 | pred rs3 | FLE |
768 Note (**TBD**): floating-point exceptions will need to be extended
769 to cater for multiple exceptions (and statuses of the same). The
770 usual approach is to have an array of status codes and bit-fields,
771 and one exception, rather than throw separate exceptions for each
774 In Hwacha EECS-2015-262 Section 6.7.2 the following pseudocode is given
775 for predicated compare operations of function "cmp":
777 for (int i=0; i<vl; ++i)
779 preg[pd][i] = cmp(s1 ? vreg[rs1][i] : sreg[rs1],
780 s2 ? vreg[rs2][i] : sreg[rs2]);
782 With associated predication, vector-length adjustments and so on,
783 and temporarily ignoring bitwidth (which makes the comparisons more
784 complex), this becomes:
786 if I/F == INT: # integer type cmp
787 preg = int_pred_reg[rd]
790 preg = fp_pred_reg[rd]
793 s1 = reg_is_vectorised(src1);
794 s2 = reg_is_vectorised(src2);
795 if (!s2 && !s1) goto branch;
796 for (int i = 0; i < VL; ++i)
797 if (cmp(s1 ? reg[src1+i]:reg[src1],
798 s2 ? reg[src2+i]:reg[src2])
799 preg[rs3] |= 1<<i; # bitfield not vector
803 * Predicated SIMD comparisons would break src1 and src2 further down
804 into bitwidth-sized chunks (see Appendix "Bitwidth Virtual Register
805 Reordering") setting Vector-Length times (number of SIMD elements) bits
806 in Predicate Register rs3 as opposed to just Vector-Length bits.
807 * Predicated Branches do not actually have an adjustment to the Program
808 Counter, so all of bits 25 through 30 in every case are not needed.
809 * There are plenty of reserved opcodes for which bits 25 through 30 could
810 be put to good use if there is a suitable use-case.
811 FLT and FLE may be inverted to FGT and FGE if needed by swapping
812 src1 and src2 (likewise the integer counterparts).
814 ## Compressed Branch Instruction:
816 Compressed Branch instructions are likewise re-interpreted as predicated
817 2-register operations, with the result going into rs3. All the bits of
818 the immediate are re-interpreted for different purposes, to extend the
819 number of comparator operations to beyond the original specification,
820 but also to cater for floating-point comparisons as well as integer ones.
823 15..13 | 12...10 | 9..7 | 6..5 | 4..2 | 1..0 | name |
824 funct3 | imm | rs10 | imm | | op | |
825 3 | 3 | 3 | 2 | 3 | 2 | |
826 C.BPR | pred rs3 | src1 | I/F B | src2 | C1 | |
827 110 | pred rs3 | src1 | I/F 0 | src2 | C1 | P.EQ |
828 111 | pred rs3 | src1 | I/F 0 | src2 | C1 | P.NE |
829 110 | pred rs3 | src1 | I/F 1 | src2 | C1 | P.LT |
830 111 | pred rs3 | src1 | I/F 1 | src2 | C1 | P.LE |
835 * Bits 5 13 14 and 15 make up the comparator type
836 * Bit 6 indicates whether to use integer or floating-point comparisons
837 * In both floating-point and integer cases there are four predication
838 comparators: EQ/NEQ/LT/LE (with GT and GE being synthesised by inverting
841 ## LOAD / STORE Instructions <a name="load_store"></a>
843 For full analysis of topological adaptation of RVV LOAD/STORE
844 see [[v_comparative_analysis]]. All three types (LD, LD.S and LD.X)
845 may be implicitly overloaded into the one base RV LOAD instruction,
846 and likewise for STORE.
851 31 | 30 | 29 25 | 24 20 | 19 15 | 14 12 | 11 7 | 6 0 |
852 imm[11:0] |||| rs1 | funct3 | rd | opcode |
853 1 | 1 | 5 | 5 | 5 | 3 | 5 | 7 |
854 ? | s | rs2 | imm[4:0] | base | width | dest | LOAD |
857 The exact same corresponding adaptation is also carried out on the single,
858 double and quad precision floating-point LOAD-FP and STORE-FP operations,
859 which fit the exact same instruction format. Thus all three types
860 (unit, stride and indexed) may be fitted into FLW, FLD and FLQ,
861 as well as FSW, FSD and FSQ.
865 * LOAD remains functionally (topologically) identical to RVV LOAD
866 (for both integer and floating-point variants).
867 * Predication CSR-marking register is not explicitly shown in instruction, it's
868 implicit based on the CSR predicate state for the rd (destination) register
869 * rs2, the source, may *also be marked as a vector*, which implicitly
870 is taken to indicate "Indexed Load" (LD.X)
871 * Bit 30 indicates "element stride" or "constant-stride" (LD or LD.S)
872 * Bit 31 is reserved (ideas under consideration: auto-increment)
873 * **TODO**: include CSR SIMD bitwidth in the pseudo-code below.
874 * **TODO**: clarify where width maps to elsize
876 Pseudo-code (excludes CSR SIMD bitwidth for simplicity):
878 if (unit-strided) stride = elsize;
879 else stride = areg[as2]; // constant-strided
881 preg = int_pred_reg[rd]
883 for (int i=0; i<vl; ++i)
884 if ([!]preg[rd] & 1<<i)
885 for (int j=0; j<seglen+1; j++)
887 if CSRvectorised[rs2])
890 offs = i*(seglen+1)*stride;
891 vreg[rd+j][i] = mem[sreg[base] + offs + j*stride];
894 Taking CSR (SIMD) bitwidth into account involves using the vector
895 length and register encoding according to the "Bitwidth Virtual Register
896 Reordering" scheme shown in the Appendix (see function "regoffs").
898 A similar instruction exists for STORE, with identical topological
899 translation of all features. **TODO**
901 ## Compressed LOAD / STORE Instructions
903 Compressed LOAD and STORE are of the same format, where bits 2-4 are
904 a src register instead of dest:
907 15 13 | 12 10 | 9 7 | 6 5 | 4 2 | 1 0 |
908 funct3 | imm | rs10 | imm | rd0 | op |
909 3 | 3 | 3 | 2 | 3 | 2 |
910 C.LW | offset[5:3] | base | offset[2|6] | dest | C0 |
913 Unfortunately it is not possible to fit the full functionality
914 of vectorised LOAD / STORE into C.LD / C.ST: the "X" variants (Indexed)
915 require another operand (rs2) in addition to the operand width
916 (which is also missing), offset, base, and src/dest.
918 However a close approximation may be achieved by taking the top bit
919 of the offset in each of the five types of LD (and ST), reducing the
920 offset to 4 bits and utilising the 5th bit to indicate whether "stride"
921 is to be enabled. In this way it is at least possible to introduce
924 (**TODO**: *assess whether the loss of one bit from offset is worth having
925 "stride" capability.*)
927 We also assume (including for the "stride" variant) that the "width"
928 parameter, which is missing, is derived and implicit, just as it is
929 with the standard Compressed LOAD/STORE instructions. For C.LW, C.LD
930 and C.LQ, the width is implicitly 4, 8 and 16 respectively, whilst for
931 C.FLW and C.FLD the width is implicitly 4 and 8 respectively.
933 Interestingly we note that the Vectorised Simple-V variant of
934 LOAD/STORE (Compressed and otherwise), due to it effectively using the
935 standard register file(s), is the direct functional equivalent of
936 standard load-multiple and store-multiple instructions found in other
939 In Section 12.3 riscv-isa manual V2.3-draft it is noted the comments on
940 page 76, "For virtual memory systems some data accesses could be resident
941 in physical memory and some not". The interesting question then arises:
942 how does RVV deal with the exact same scenario?
943 Expired U.S. Patent 5895501 (Filing Date Sep 3 1996) describes a method
944 of detecting early page / segmentation faults and adjusting the TLB
945 in advance, accordingly: other strategies are explored in the Appendix
946 Section "Virtual Memory Page Faults".
948 ## Vectorised Copy/Move (and conversion) instructions
950 There is a series of 2-operand instructions involving copying (and
951 alteration): C.MV, FMV, FNEG, FABS, FCVT, FSGNJ. These operations all
952 follow the same pattern, as it is *both* the source *and* destination
953 predication masks that are taken into account. This is different from
954 the three-operand arithmetic instructions, where the predication mask
955 is taken from the *destination* register, and applied uniformly to the
956 elements of the source register(s), element-for-element.
958 ### C.MV Instruction <a name="c_mv"></a>
960 There is no MV instruction in RV however there is a C.MV instruction.
961 It is used for copying integer-to-integer registers (vectorised FMV
962 is used for copying floating-point).
964 If either the source or the destination register are marked as vectors
965 C.MV is reinterpreted to be a vectorised (multi-register) predicated
966 move operation. The actual instruction's format does not change:
969 15 12 | 11 7 | 6 2 | 1 0 |
970 funct4 | rd | rs | op |
972 C.MV | dest | src | C0 |
975 A simplified version of the pseudocode for this operation is as follows:
977 function op_mv(rd, rs) # MV not VMV!
978 rd = int_vec[rd].isvector ? int_vec[rd].regidx : rd;
979 rs = int_vec[rs].isvector ? int_vec[rs].regidx : rs;
980 ps = get_pred_val(FALSE, rs); # predication on src
981 pd = get_pred_val(FALSE, rd); # ... AND on dest
982 for (int i = 0, int j = 0; i < VL && j < VL;):
983 if (int_vec[rs].isvec) while (!(ps & 1<<i)) i++;
984 if (int_vec[rd].isvec) while (!(pd & 1<<j)) j++;
985 ireg[rd+j] <= ireg[rs+i];
986 if (int_vec[rs].isvec) i++;
987 if (int_vec[rd].isvec) j++;
991 * elwidth (SIMD) is not covered above
992 * ending the loop early in scalar cases (VINSERT, VEXTRACT) is also
995 There are several different instructions from RVV that are covered by
999 src | dest | predication | op |
1000 scalar | vector | none | VSPLAT |
1001 scalar | vector | destination | sparse VSPLAT |
1002 scalar | vector | 1-bit dest | VINSERT |
1003 vector | scalar | 1-bit? src | VEXTRACT |
1004 vector | vector | none | VCOPY |
1005 vector | vector | src | Vector Gather |
1006 vector | vector | dest | Vector Scatter |
1007 vector | vector | src & dest | Gather/Scatter |
1008 vector | vector | src == dest | sparse VCOPY |
1011 Also, VMERGE may be implemented as back-to-back (macro-op fused) C.MV
1012 operations with inversion on the src and dest predication for one of the
1013 two C.MV operations.
1015 Note that in the instance where the Compressed Extension is not implemented,
1016 MV may be used, but that is a pseudo-operation mapping to addi rd, x0, rs.
1017 Note that the behaviour is **different** from C.MV because with addi the
1018 predication mask to use is taken **only** from rd and is applied against
1019 all elements: rs[i] = rd[i].
1021 ### FMV, FNEG and FABS Instructions
1023 These are identical in form to C.MV, except covering floating-point
1024 register copying. The same double-predication rules also apply.
1025 However when elwidth is not set to default the instruction is implicitly
1026 and automatic converted to a (vectorised) floating-point type conversion
1027 operation of the appropriate size covering the source and destination
1030 (Note that FMV, FNEG and FABS are all actually pseudo-instructions)
1032 ### FVCT Instructions
1034 These are again identical in form to C.MV, except that they cover
1035 floating-point to integer and integer to floating-point. When element
1036 width in each vector is set to default, the instructions behave exactly
1037 as they are defined for standard RV (scalar) operations, except vectorised
1038 in exactly the same fashion as outlined in C.MV.
1040 However when the source or destination element width is not set to default,
1041 the opcode's explicit element widths are *over-ridden* to new definitions,
1042 and the opcode's element width is taken as indicative of the SIMD width
1043 (if applicable i.e. if packed SIMD is requested) instead.
1045 For example FCVT.S.L would normally be used to convert a 64-bit
1046 integer in register rs1 to a 64-bit floating-point number in rd.
1047 If however the source rs1 is set to be a vector, where elwidth is set to
1048 default/2 and "packed SIMD" is enabled, then the first 32 bits of
1049 rs1 are converted to a floating-point number to be stored in rd's
1050 first element and the higher 32-bits *also* converted to floating-point
1051 and stored in the second. The 32 bit size comes from the fact that
1052 FCVT.S.L's integer width is 64 bit, and with elwidth on rs1 set to
1053 divide that by two it means that rs1 element width is to be taken as 32.
1055 Similar rules apply to the destination register.
1059 > What does an ADD of two different-sized vectors do in simple-V?
1061 * if the two source operands are not the same, throw an exception.
1062 * if the destination operand is also a vector, and the source is longer
1063 than the destination, throw an exception.
1065 > And what about instructions like JALR?
1066 > What does jumping to a vector do?
1068 * Throw an exception. Whether that actually results in spawning threads
1069 as part of the trap-handling remains to be seen.
1071 # Under consideration
1073 From the Chennai 2018 slides the following issues were raised.
1074 Efforts to analyse and answer these questions are below.
1076 * Should future extra bank be included now?
1077 * How many Register and Predication CSRs should there be?
1078 (and how many in RV32E)
1079 * How many in M-Mode (for doing context-switch)?
1080 * Should use of registers be allowed to "wrap" (x30 x31 x1 x2)?
1081 * Can CLIP be done as a CSR (mode, like elwidth)
1082 * SIMD saturation (etc.) also set as a mode?
1083 * Include src1/src2 predication on Comparison Ops?
1084 (same arrangement as C.MV, with same flexibility/power)
1085 * 8/16-bit ops is it worthwhile adding a "start offset"?
1086 (a bit like misaligned addressing... for registers)
1087 or just use predication to skip start?
1089 ## Future (extra) bank be included (made mandatory)
1091 The implications of expanding the *standard* register file from
1092 32 entries per bank to 64 per bank is quite an extensive architectural
1093 change. Also it has implications for context-switching.
1095 Therefore, on balance, it is not recommended and certainly should
1096 not be made a *mandatory* requirement for the use of SV. SV's design
1097 ethos is to be minimally-disruptive for implementors to shoe-horn
1098 into an existing design.
1100 ## How large should the Register and Predication CSR key-value stores be?
1102 This is something that definitely needs actual evaluation and for
1103 code to be run and the results analysed. At the time of writing
1104 (12jul2018) that is too early to tell. An approximate best-guess
1105 however would be 16 entries.
1107 RV32E however is a special case, given that it is highly unlikely
1108 (but not outside the realm of possibility) that it would be used
1109 for performance reasons but instead for reducing instruction count.
1110 The number of CSR entries therefore has to be considered extremely
1113 ## How many CSR entries in M-Mode or S-Mode (for context-switching)?
1115 The minimum required CSR entries would be 1 for each register-bank:
1116 one for integer and one for floating-point. However, as shown
1117 in the "Context Switch Example" section, for optimal efficiency
1118 (minimal instructions in a low-latency situation) the CSRs for
1119 the context-switch should be set up *and left alone*.
1121 This means that it is not really a good idea to touch the CSRs
1122 used for context-switching in the M-Mode (or S-Mode) trap, so
1123 if there is ever demonstrated a need for vectors then there would
1124 need to be *at least* one more free. However just one does not make
1125 much sense (as it one only covers scalar-vector ops) so it is more
1126 likely that at least two extra would be needed.
1128 This *in addition* - in the RV32E case - if an RV32E implementation
1129 happens also to support U/S/M modes. This would be considered quite
1130 rare but not outside of the realm of possibility.
1132 Conclusion: all needs careful analysis and future work.
1134 ## Should use of registers be allowed to "wrap" (x30 x31 x1 x2)?
1136 On balance it's a neat idea however it does seem to be one where the
1137 benefits are not really clear. It would however obviate the need for
1138 an exception to be raised if the VL runs out of registers to put
1139 things in (gets to x31, tries a non-existent x32 and fails), however
1140 the "fly in the ointment" is that x0 is hard-coded to "zero". The
1141 increment therefore would need to be double-stepped to skip over x0.
1142 Some microarchitectures could run into difficulties (SIMD-like ones
1143 in particular) so it needs a lot more thought.
1145 ## Can CLIP be done as a CSR (mode, like elwidth)
1147 RVV appears to be going this way. At the time of writing (12jun2018)
1148 it's noted that in V2.3-Draft V0.4 RVV Chapter, RVV intends to do
1149 clip by way of exactly this method: setting a "clip mode" in a CSR.
1151 No details are given however the most sensible thing to have would be
1152 to extend the 16-bit Register CSR table to 24-bit (or 32-bit) and have
1153 extra bits specifying the type of clipping to be carried out, on
1154 a per-register basis. Other bits may be used for other purposes
1155 (see SIMD saturation below)
1157 ## SIMD saturation (etc.) also set as a mode?
1159 Similar to "CLIP" as an extension to the CSR key-value store, "saturate"
1160 may also need extra details (what the saturation maximum is for example).
1162 ## Include src1/src2 predication on Comparison Ops?
1164 In the C.MV (and other ops - see "C.MV Instruction"), the decision
1165 was taken, unlike in ADD (etc.) which are 3-operand ops, to use
1166 *both* the src *and* dest predication masks to give an extremely
1167 powerful and flexible instruction that covers a huge number of
1168 "traditional" vector opcodes.
1170 The natural question therefore to ask is: where else could this
1171 flexibility be deployed? What about comparison operations?
1173 Unfortunately, C.MV is basically "regs[dest] = regs[src]" whilst
1174 predicated comparison operations are actually a *three* operand
1177 regs[pred] |= 1<< (cmp(regs[src1], regs[src2]) ? 1 : 0)
1179 Therefore at first glance it does not make sense to use src1 and src2
1180 predication masks, as it breaks the rule of 3-operand instructions
1181 to use the *destination* predication register.
1183 In this case however, the destination *is* a predication register
1184 as opposed to being a predication mask that is applied *to* the
1185 (vectorised) operation, element-at-a-time on src1 and src2.
1187 Thus the question is directly inter-related to whether the modification
1188 of the predication mask should *itself* be predicated.
1190 It is quite complex, in other words, and needs careful consideration.
1192 ## 8/16-bit ops is it worthwhile adding a "start offset"?
1194 The idea here is to make it possible, particularly in a "Packed SIMD"
1195 case, to be able to avoid doing unaligned Load/Store operations
1196 by specifying that operations, instead of being carried out
1197 element-for-element, are offset by a fixed amount *even* in 8 and 16-bit
1198 element Packed SIMD cases.
1200 For example rather than take 2 32-bit registers divided into 4 8-bit
1201 elements and have them ADDed element-for-element as follows:
1203 r3[0] = add r4[0], r6[0]
1204 r3[1] = add r4[1], r6[1]
1205 r3[2] = add r4[2], r6[2]
1206 r3[3] = add r4[3], r6[3]
1208 an offset of 1 would result in four operations as follows, instead:
1210 r3[0] = add r4[1], r6[0]
1211 r3[1] = add r4[2], r6[1]
1212 r3[2] = add r4[3], r6[2]
1213 r3[3] = add r5[0], r6[3]
1215 In non-packed-SIMD mode there is no benefit at all, as a vector may
1216 be created using a different CSR that has the offset built-in. So this
1217 leaves just the packed-SIMD case to consider.
1219 Two ways in which this could be implemented / emulated (without special
1222 * bit-manipulation that shuffles the data along by one byte (or one word)
1223 either prior to or as part of the operation requiring the offset.
1224 * just use an unaligned Load/Store sequence, even if there are performance
1225 penalties for doing so.
1227 The question then is whether the performance hit is worth the extra hardware
1228 involving byte-shuffling/shifting the data by an arbitrary offset. On
1229 balance given that there are two reasonable instruction-based options, the
1230 hardware-offset option should be left out for the initial version of SV,
1231 with the option to consider it in an "advanced" version of the specification.
1233 # Impementing V on top of Simple-V
1235 With Simple-V converting the original RVV draft concept-for-concept
1236 from explicit opcodes to implicit overloading of existing RV Standard
1237 Extensions, certain features were (deliberately) excluded that need
1238 to be added back in for RVV to reach its full potential. This is
1239 made slightly complicated by the fact that RVV itself has two
1240 levels: Base and reserved future functionality.
1242 * Representation Encoding is entirely left out of Simple-V in favour of
1243 implicitly taking the exact (explicit) meaning from RV Standard Extensions.
1244 * VCLIP and VCLIPI do not have corresponding RV Standard Extension
1245 opcodes (and are the only such operations).
1246 * Extended Element bitwidths (1 through to 24576 bits) were left out
1247 of Simple-V as, again, there is no corresponding RV Standard Extension
1248 that covers anything even below 32-bit operands.
1249 * Polymorphism was entirely left out of Simple-V due to the inherent
1250 complexity of automatic type-conversion.
1251 * Vector Register files were specifically left out of Simple-V in favour
1252 of fitting on top of the integer and floating-point files. An
1253 "RVV re-retro-fit" needs to be able to mark (implicitly marked)
1254 registers as being actually in a separate *vector* register file.
1255 * Fortunately in RVV (Draft 0.4, V2.3-Draft), the "base" vector
1256 register file size is 5 bits (32 registers), whilst the "Extended"
1257 variant of RVV specifies 8 bits (256 registers) and has yet to
1259 * One big difference: Sections 17.12 and 17.17, there are only two possible
1260 predication registers in RVV "Base". Through the "indirect" method,
1261 Simple-V provides a key-value CSR table that allows (arbitrarily)
1262 up to 16 (TBD) of either the floating-point or integer registers to
1263 be marked as "predicated" (key), and if so, which integer register to
1264 use as the predication mask (value).
1268 # Implementing P (renamed to DSP) on top of Simple-V
1270 * Implementors indicate chosen bitwidth support in Vector-bitwidth CSR
1271 (caveat: anything not specified drops through to software-emulation / traps)
1276 ## V-Extension to Simple-V Comparative Analysis
1278 This section has been moved to its own page [[v_comparative_analysis]]
1282 This section has been moved to its own page [[p_comparative_analysis]]
1284 ## Comparison of "Traditional" SIMD, Alt-RVP, Simple-V and RVV Proposals <a name="parallelism_comparisons"></a>
1286 This section compares the various parallelism proposals as they stand,
1287 including traditional SIMD, in terms of features, ease of implementation,
1288 complexity, flexibility, and die area.
1290 ### [[harmonised_rvv_rvp]]
1292 This is an interesting proposal under development to retro-fit the AndesStar
1297 Primary benefit of Alt-RVP is the simplicity with which parallelism
1298 may be introduced (effective multiplication of regfiles and associated ALUs).
1300 * plus: the simplicity of the lanes (combined with the regularity of
1301 allocating identical opcodes multiple independent registers) meaning
1302 that SRAM or 2R1W can be used for entire regfile (potentially).
1303 * minus: a more complex instruction set where the parallelism is much
1304 more explicitly directly specified in the instruction and
1305 * minus: if you *don't* have an explicit instruction (opcode) and you
1306 need one, the only place it can be added is... in the vector unit and
1307 * minus: opcode functions (and associated ALUs) duplicated in Alt-RVP are
1308 not useable or accessible in other Extensions.
1309 * plus-and-minus: Lanes may be utilised for high-speed context-switching
1310 but with the down-side that they're an all-or-nothing part of the Extension.
1311 No Alt-RVP: no fast register-bank switching.
1312 * plus: Lane-switching would mean that complex operations not suited to
1313 parallelisation can be carried out, followed by further parallel Lane-based
1314 work, without moving register contents down to memory (and back)
1315 * minus: Access to registers across multiple lanes is challenging. "Solution"
1316 is to drop data into memory and immediately back in again (like MMX).
1320 Primary benefit of Simple-V is the OO abstraction of parallel principles
1321 from actual (internal) parallel hardware. It's an API in effect that's
1322 designed to be slotted in to an existing implementation (just after
1323 instruction decode) with minimum disruption and effort.
1325 * minus: the complexity (if full parallelism is to be exploited)
1326 of having to use register renames, OoO, VLIW, register file cacheing,
1327 all of which has been done before but is a pain
1328 * plus: transparent re-use of existing opcodes as-is just indirectly
1329 saying "this register's now a vector" which
1330 * plus: means that future instructions also get to be inherently
1331 parallelised because there's no "separate vector opcodes"
1332 * plus: Compressed instructions may also be (indirectly) parallelised
1333 * minus: the indirect nature of Simple-V means that setup (setting
1334 a CSR register to indicate vector length, a separate one to indicate
1335 that it is a predicate register and so on) means a little more setup
1336 time than Alt-RVP or RVV's "direct and within the (longer) instruction"
1338 * plus: shared register file meaning that, like Alt-RVP, complex
1339 operations not suited to parallelisation may be carried out interleaved
1340 between parallelised instructions *without* requiring data to be dropped
1341 down to memory and back (into a separate vectorised register engine).
1342 * plus-and-maybe-minus: re-use of integer and floating-point 32-wide register
1343 files means that huge parallel workloads would use up considerable
1344 chunks of the register file. However in the case of RV64 and 32-bit
1345 operations, that effectively means 64 slots are available for parallel
1347 * plus: inherent parallelism (actual parallel ALUs) doesn't actually need to
1348 be added, yet the instruction opcodes remain unchanged (and still appear
1349 to be parallel). consistent "API" regardless of actual internal parallelism:
1350 even an in-order single-issue implementation with a single ALU would still
1351 appear to have parallel vectoristion.
1352 * hard-to-judge: if actual inherent underlying ALU parallelism is added it's
1353 hard to say if there would be pluses or minuses (on die area). At worse it
1354 would be "no worse" than existing register renaming, OoO, VLIW and register
1355 file cacheing schemes.
1357 ### RVV (as it stands, Draft 0.4 Section 17, RISC-V ISA V2.3-Draft)
1359 RVV is extremely well-designed and has some amazing features, including
1360 2D reorganisation of memory through LOAD/STORE "strides".
1362 * plus: regular predictable workload means that implementations may
1363 streamline effects on L1/L2 Cache.
1364 * plus: regular and clear parallel workload also means that lanes
1365 (similar to Alt-RVP) may be used as an implementation detail,
1366 using either SRAM or 2R1W registers.
1367 * plus: separate engine with no impact on the rest of an implementation
1368 * minus: separate *complex* engine with no RTL (ALUs, Pipeline stages) reuse
1370 * minus: no ISA abstraction or re-use either: additions to other Extensions
1371 do not gain parallelism, resulting in prolific duplication of functionality
1372 inside RVV *and out*.
1373 * minus: when operations require a different approach (scalar operations
1374 using the standard integer or FP regfile) an entire vector must be
1375 transferred out to memory, into standard regfiles, then back to memory,
1376 then back to the vector unit, this to occur potentially multiple times.
1377 * minus: will never fit into Compressed instruction space (as-is. May
1378 be able to do so if "indirect" features of Simple-V are partially adopted).
1379 * plus-and-slight-minus: extended variants may address up to 256
1380 vectorised registers (requires 48/64-bit opcodes to do it).
1381 * minus-and-partial-plus: separate engine plus complexity increases
1382 implementation time and die area, meaning that adoption is likely only
1383 to be in high-performance specialist supercomputing (where it will
1384 be absolutely superb).
1386 ### Traditional SIMD
1388 The only really good things about SIMD are how easy it is to implement and
1389 get good performance. Unfortunately that makes it quite seductive...
1391 * plus: really straightforward, ALU basically does several packed operations
1392 at once. Parallelism is inherent at the ALU, making the addition of
1393 SIMD-style parallelism an easy decision that has zero significant impact
1394 on the rest of any given architectural design and layout.
1395 * plus (continuation): SIMD in simple in-order single-issue designs can
1396 therefore result in superb throughput, easily achieved even with a very
1397 simple execution model.
1398 * minus: ridiculously complex setup and corner-cases that disproportionately
1399 increase instruction count on what would otherwise be a "simple loop",
1400 should the number of elements in an array not happen to exactly match
1401 the SIMD group width.
1402 * minus: getting data usefully out of registers (if separate regfiles
1403 are used) means outputting to memory and back.
1404 * minus: quite a lot of supplementary instructions for bit-level manipulation
1405 are needed in order to efficiently extract (or prepare) SIMD operands.
1406 * minus: MASSIVE proliferation of ISA both in terms of opcodes in one
1407 dimension and parallelism (width): an at least O(N^2) and quite probably
1408 O(N^3) ISA proliferation that often results in several thousand
1409 separate instructions. all requiring separate and distinct corner-case
1411 * minus: EVEN BIGGER proliferation of SIMD ISA if the functionality of
1412 8, 16, 32 or 64-bit reordering is built-in to the SIMD instruction.
1413 For example: add (high|low) 16-bits of r1 to (low|high) of r2 requires
1414 four separate and distinct instructions: one for (r1:low r2:high),
1415 one for (r1:high r2:low), one for (r1:high r2:high) and one for
1416 (r1:low r2:low) *per function*.
1417 * minus: EVEN BIGGER proliferation of SIMD ISA if there is a mismatch
1418 between operand and result bit-widths. In combination with high/low
1419 proliferation the situation is made even worse.
1420 * minor-saving-grace: some implementations *may* have predication masks
1421 that allow control over individual elements within the SIMD block.
1423 ## Comparison *to* Traditional SIMD: Alt-RVP, Simple-V and RVV Proposals <a name="simd_comparison"></a>
1425 This section compares the various parallelism proposals as they stand,
1426 *against* traditional SIMD as opposed to *alongside* SIMD. In other words,
1427 the question is asked "How can each of the proposals effectively implement
1428 (or replace) SIMD, and how effective would they be"?
1432 * Alt-RVP would not actually replace SIMD but would augment it: just as with
1433 a SIMD architecture where the ALU becomes responsible for the parallelism,
1434 Alt-RVP ALUs would likewise be so responsible... with *additional*
1435 (lane-based) parallelism on top.
1436 * Thus at least some of the downsides of SIMD ISA O(N^5) proliferation by
1437 at least one dimension are avoided (architectural upgrades introducing
1438 128-bit then 256-bit then 512-bit variants of the exact same 64-bit
1440 * Thus, unfortunately, Alt-RVP would suffer the same inherent proliferation
1441 of instructions as SIMD, albeit not quite as badly (due to Lanes).
1442 * In the same discussion for Alt-RVP, an additional proposal was made to
1443 be able to subdivide the bits of each register lane (columns) down into
1444 arbitrary bit-lengths (RGB 565 for example).
1445 * A recommendation was given instead to make the subdivisions down to 32-bit,
1446 16-bit or even 8-bit, effectively dividing the registerfile into
1447 Lane0(H), Lane0(L), Lane1(H) ... LaneN(L) or further. If inter-lane
1448 "swapping" instructions were then introduced, some of the disadvantages
1449 of SIMD could be mitigated.
1453 * RVV is designed to replace SIMD with a better paradigm: arbitrary-length
1455 * However whilst SIMD is usually designed for single-issue in-order simple
1456 DSPs with a focus on Multimedia (Audio, Video and Image processing),
1457 RVV's primary focus appears to be on Supercomputing: optimisation of
1458 mathematical operations that fit into the OpenCL space.
1459 * Adding functions (operations) that would normally fit (in parallel)
1460 into a SIMD instruction requires an equivalent to be added to the
1461 RVV Extension, if one does not exist. Given the specialist nature of
1462 some SIMD instructions (8-bit or 16-bit saturated or halving add),
1463 this possibility seems extremely unlikely to occur, even if the
1464 implementation overhead of RVV were acceptable (compared to
1465 normal SIMD/DSP-style single-issue in-order simplicity).
1469 * Simple-V borrows hugely from RVV as it is intended to be easy to
1470 topologically transplant every single instruction from RVV (as
1471 designed) into Simple-V equivalents, with *zero loss of functionality
1473 * With the "parallelism" abstracted out, a hypothetical SIMD-less "DSP"
1474 Extension which contained the basic primitives (non-parallelised
1475 8, 16 or 32-bit SIMD operations) inherently *become* parallel,
1477 * Additionally, standard operations (ADD, MUL) that would normally have
1478 to have special SIMD-parallel opcodes added need no longer have *any*
1479 of the length-dependent variants (2of 32-bit ADDs in a 64-bit register,
1480 4of 32-bit ADDs in a 128-bit register) because Simple-V takes the
1481 *standard* RV opcodes (present and future) and automatically parallelises
1483 * By inheriting the RVV feature of arbitrary vector-length, then just as
1484 with RVV the corner-cases and ISA proliferation of SIMD is avoided.
1485 * Whilst not entirely finalised, registers are expected to be
1486 capable of being subdivided down to an implementor-chosen bitwidth
1487 in the underlying hardware (r1 becomes r1[31..24] r1[23..16] r1[15..8]
1488 and r1[7..0], or just r1[31..16] r1[15..0]) where implementors can
1489 choose to have separate independent 8-bit ALUs or dual-SIMD 16-bit
1490 ALUs that perform twin 8-bit operations as they see fit, or anything
1491 else including no subdivisions at all.
1492 * Even though implementors have that choice even to have full 64-bit
1493 (with RV64) SIMD, they *must* provide predication that transparently
1494 switches off appropriate units on the last loop, thus neatly fitting
1495 underlying SIMD ALU implementations *into* the arbitrary vector-length
1496 RVV paradigm, keeping the uniform consistent API that is a key strategic
1497 feature of Simple-V.
1498 * With Simple-V fitting into the standard register files, certain classes
1499 of SIMD operations such as High/Low arithmetic (r1[31..16] + r2[15..0])
1500 can be done by applying *Parallelised* Bit-manipulation operations
1501 followed by parallelised *straight* versions of element-to-element
1502 arithmetic operations, even if the bit-manipulation operations require
1503 changing the bitwidth of the "vectors" to do so. Predication can
1504 be utilised to skip high words (or low words) in source or destination.
1505 * In essence, the key downside of SIMD - massive duplication of
1506 identical functions over time as an architecture evolves from 32-bit
1507 wide SIMD all the way up to 512-bit, is avoided with Simple-V, through
1508 vector-style parallelism being dropped on top of 8-bit or 16-bit
1509 operations, all the while keeping a consistent ISA-level "API" irrespective
1510 of implementor design choices (or indeed actual implementations).
1512 ### Example Instruction translation: <a name="example_translation"></a>
1514 Instructions "ADD r2 r4 r4" would result in three instructions being
1515 generated and placed into the FIFO:
1521 ## Example of vector / vector, vector / scalar, scalar / scalar => vector add
1523 register CSRvectorlen[XLEN][4]; # not quite decided yet about this one...
1524 register CSRpredicate[XLEN][4]; # 2^4 is max vector length
1525 register CSRreg_is_vectorised[XLEN]; # just for fun support scalars as well
1526 register x[32][XLEN];
1528 function op_add(rd, rs1, rs2, predr)
1530 /* note that this is ADD, not PADD */
1531 int i, id, irs1, irs2;
1532 # checks CSRvectorlen[rd] == CSRvectorlen[rs] etc. ignored
1533 # also destination makes no sense as a scalar but what the hell...
1534 for (i = 0, id=0, irs1=0, irs2=0; i<CSRvectorlen[rd]; i++)
1535 if (CSRpredicate[predr][i]) # i *think* this is right...
1536 x[rd+id] <= x[rs1+irs1] + x[rs2+irs2];
1537 # now increment the idxs
1538 if (CSRreg_is_vectorised[rd]) # bitfield check rd, scalar/vector?
1540 if (CSRreg_is_vectorised[rs1]) # bitfield check rs1, scalar/vector?
1542 if (CSRreg_is_vectorised[rs2]) # bitfield check rs2, scalar/vector?
1546 ## Retro-fitting Predication into branch-explicit ISA <a name="predication_retrofit"></a>
1548 One of the goals of this parallelism proposal is to avoid instruction
1549 duplication. However, with the base ISA having been designed explictly
1550 to *avoid* condition-codes entirely, shoe-horning predication into it
1551 bcomes quite challenging.
1553 However what if all branch instructions, if referencing a vectorised
1554 register, were instead given *completely new analogous meanings* that
1555 resulted in a parallel bit-wise predication register being set? This
1556 would have to be done for both C.BEQZ and C.BNEZ, as well as BEQ, BNE,
1559 We might imagine that FEQ, FLT and FLT would also need to be converted,
1560 however these are effectively *already* in the precise form needed and
1561 do not need to be converted *at all*! The difference is that FEQ, FLT
1562 and FLE *specifically* write a 1 to an integer register if the condition
1563 holds, and 0 if not. All that needs to be done here is to say, "if
1564 the integer register is tagged with a bit that says it is a predication
1565 register, the **bit** in the integer register is set based on the
1566 current vector index" instead.
1568 There is, in the standard Conditional Branch instruction, more than
1569 adequate space to interpret it in a similar fashion:
1572 31 |30 ..... 25 |24..20|19..15| 14...12| 11.....8 | 7 | 6....0 |
1573 imm[12] | imm[10:5] |rs2 | rs1 | funct3 | imm[4:1] | imm[11] | opcode |
1574 1 | 6 | 5 | 5 | 3 | 4 | 1 | 7 |
1575 offset[12,10:5] || src2 | src1 | BEQ | offset[11,4:1] || BRANCH |
1581 31 | 30 .. 25 |24 ... 20 | 19 15 | 14 12 | 11 .. 8 | 7 | 6 ... 0 |
1582 imm[12] | imm[10:5]| rs2 | rs1 | funct3 | imm[4:1] | imm[11] | opcode |
1583 1 | 6 | 5 | 5 | 3 | 4 | 1 | 7 |
1584 reserved || src2 | src1 | BEQ | predicate rs3 || BRANCH |
1587 Similarly the C.BEQZ and C.BNEZ instruction format may be retro-fitted,
1588 with the interesting side-effect that there is space within what is presently
1589 the "immediate offset" field to reinterpret that to add in not only a bit
1590 field to distinguish between floating-point compare and integer compare,
1591 not only to add in a second source register, but also use some of the bits as
1592 a predication target as well.
1595 15..13 | 12 ....... 10 | 9...7 | 6 ......... 2 | 1 .. 0 |
1596 funct3 | imm | rs10 | imm | op |
1598 C.BEQZ | offset[8,4:3] | src | offset[7:6,2:1,5] | C1 |
1601 Now uses the CS format:
1604 15..13 | 12 . 10 | 9 .. 7 | 6 .. 5 | 4..2 | 1 .. 0 |
1605 funct3 | imm | rs10 | imm | | op |
1606 3 | 3 | 3 | 2 | 3 | 2 |
1607 C.BEQZ | pred rs3 | src1 | I/F B | src2 | C1 |
1610 Bit 6 would be decoded as "operation refers to Integer or Float" including
1611 interpreting src1 and src2 accordingly as outlined in Table 12.2 of the
1612 "C" Standard, version 2.0,
1613 whilst Bit 5 would allow the operation to be extended, in combination with
1614 funct3 = 110 or 111: a combination of four distinct (predicated) comparison
1615 operators. In both floating-point and integer cases those could be
1616 EQ/NEQ/LT/LE (with GT and GE being synthesised by inverting src1 and src2).
1618 ## Register reordering <a name="register_reordering"></a>
1637 May not be an actual CSR: may be generated from Vector Length CSR:
1638 single-bit is less burdensome on instruction decode phase.
1640 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
1641 | - | - | - | - | - | - | - | - |
1642 | 0 | 0 | 0 | 1 | 0 | 0 | 0 | 1 |
1644 ### Vector Length CSR
1646 | Reg Num | (3..0) |
1657 ### Virtual Register Reordering
1659 This example assumes the above Vector Length CSR table
1661 | Reg Num | Bits (0) | Bits (1) | Bits (2) |
1662 | ------- | -------- | -------- | -------- |
1663 | r0 | (32..0) | (32..0) |
1666 | r4 | (32..0) | (32..0) | (32..0) |
1669 ### Bitwidth Virtual Register Reordering
1671 This example goes a little further and illustrates the effect that a
1672 bitwidth CSR has been set on a register. Preconditions:
1675 * CSRintbitwidth[2] = 010 # integer r2 is 16-bit
1676 * CSRintvlength[2] = 3 # integer r2 is a vector of length 3
1677 * vsetl rs1, 5 # set the vector length to 5
1679 This is interpreted as follows:
1681 * Given that the context is RV32, ELEN=32.
1682 * With ELEN=32 and bitwidth=16, the number of SIMD elements is 2
1683 * Therefore the actual vector length is up to *six* elements
1684 * However vsetl sets a length 5 therefore the last "element" is skipped
1686 So when using an operation that uses r2 as a source (or destination)
1687 the operation is carried out as follows:
1689 * 16-bit operation on r2(15..0) - vector element index 0
1690 * 16-bit operation on r2(31..16) - vector element index 1
1691 * 16-bit operation on r3(15..0) - vector element index 2
1692 * 16-bit operation on r3(31..16) - vector element index 3
1693 * 16-bit operation on r4(15..0) - vector element index 4
1694 * 16-bit operation on r4(31..16) **NOT** carried out due to length being 5
1696 Predication has been left out of the above example for simplicity, however
1697 predication is ANDed with the latter stages (vsetl not equal to maximum
1700 Note also that it is entirely an implementor's choice as to whether to have
1701 actual separate ALUs down to the minimum bitwidth, or whether to have something
1702 more akin to traditional SIMD (at any level of subdivision: 8-bit SIMD
1703 operations carried out 32-bits at a time is perfectly acceptable, as is
1704 8-bit SIMD operations carried out 16-bits at a time requiring two ALUs).
1705 Regardless of the internal parallelism choice, *predication must
1706 still be respected*, making Simple-V in effect the "consistent public API".
1708 vew may be one of the following (giving a table "bytestable", used below):
1710 | vew | bitwidth | bytestable |
1711 | --- | -------- | ---------- |
1712 | 000 | default | XLEN/8 |
1718 | 110 | rsvd | rsvd |
1719 | 111 | rsvd | rsvd |
1721 Pseudocode for vector length taking CSR SIMD-bitwidth into account:
1723 vew = CSRbitwidth[rs1]
1725 bytesperreg = (XLEN/8) # or FLEN as appropriate
1727 bytesperreg = bytestable[vew] # 1 2 4 8 16
1728 simdmult = (XLEN/8) / bytesperreg # or FLEN as appropriate
1729 vlen = CSRvectorlen[rs1] * simdmult
1731 To index an element in a register rnum where the vector element index is i:
1733 function regoffs(rnum, i):
1734 regidx = floor(i / simdmult) # integer-div rounded down
1735 byteidx = i % simdmult # integer-remainder
1736 return rnum + regidx, # actual real register
1738 byteidx * 8 + (vew-1), # high
1742 SIMD register file splitting still to consider. For RV64, benefits of doubling
1743 (quadrupling in the case of Half-Precision IEEE754 FP) the apparent
1744 size of the floating point register file to 64 (128 in the case of HP)
1745 seem pretty clear and worth the complexity.
1747 64 virtual 32-bit F.P. registers and given that 32-bit FP operations are
1748 done on 64-bit registers it's not so conceptually difficult. May even
1749 be achieved by *actually* splitting the regfile into 64 virtual 32-bit
1750 registers such that a 64-bit FP scalar operation is dropped into (r0.H
1751 r0.L) tuples. Implementation therefore hidden through register renaming.
1753 Implementations intending to introduce VLIW, OoO and parallelism
1754 (even without Simple-V) would then find that the instructions are
1755 generated quicker (or in a more compact fashion that is less heavy
1756 on caches). Interestingly we observe then that Simple-V is about
1757 "consolidation of instruction generation", where actual parallelism
1758 of underlying hardware is an implementor-choice that could just as
1759 equally be applied *without* Simple-V even being implemented.
1761 ## Analysis of CSR decoding on latency <a name="csr_decoding_analysis"></a>
1763 It could indeed have been logically deduced (or expected), that there
1764 would be additional decode latency in this proposal, because if
1765 overloading the opcodes to have different meanings, there is guaranteed
1766 to be some state, some-where, directly related to registers.
1768 There are several cases:
1770 * All operands vector-length=1 (scalars), all operands
1771 packed-bitwidth="default": instructions are passed through direct as if
1772 Simple-V did not exist. Simple-V is, in effect, completely disabled.
1773 * At least one operand vector-length > 1, all operands
1774 packed-bitwidth="default": any parallel vector ALUs placed on "alert",
1775 virtual parallelism looping may be activated.
1776 * All operands vector-length=1 (scalars), at least one
1777 operand packed-bitwidth != default: degenerate case of SIMD,
1778 implementation-specific complexity here (packed decode before ALUs or
1780 * At least one operand vector-length > 1, at least one operand
1781 packed-bitwidth != default: parallel vector ALUs (if any)
1782 placed on "alert", virtual parallelsim looping may be activated,
1783 implementation-specific SIMD complexity kicks in (packed decode before
1786 Bear in mind that the proposal includes that the decision whether
1787 to parallelise in hardware or whether to virtual-parallelise (to
1788 dramatically simplify compilers and also not to run into the SIMD
1789 instruction proliferation nightmare) *or* a transprent combination
1790 of both, be done on a *per-operand basis*, so that implementors can
1791 specifically choose to create an application-optimised implementation
1792 that they believe (or know) will sell extremely well, without having
1793 "Extra Standards-Mandated Baggage" that would otherwise blow their area
1794 or power budget completely out the window.
1796 Additionally, two possible CSR schemes have been proposed, in order to
1797 greatly reduce CSR space:
1799 * per-register CSRs (vector-length and packed-bitwidth)
1800 * a smaller number of CSRs with the same information but with an *INDEX*
1801 specifying WHICH register in one of three regfiles (vector, fp, int)
1802 the length and bitwidth applies to.
1804 (See "CSR vector-length and CSR SIMD packed-bitwidth" section for details)
1806 In addition, LOAD/STORE has its own associated proposed CSRs that
1807 mirror the STRIDE (but not yet STRIDE-SEGMENT?) functionality of
1810 Also bear in mind that, for reasons of simplicity for implementors,
1811 I was coming round to the idea of permitting implementors to choose
1812 exactly which bitwidths they would like to support in hardware and which
1813 to allow to fall through to software-trap emulation.
1815 So the question boils down to:
1817 * whether either (or both) of those two CSR schemes have significant
1818 latency that could even potentially require an extra pipeline decode stage
1819 * whether there are implementations that can be thought of which do *not*
1820 introduce significant latency
1821 * whether it is possible to explicitly (through quite simply
1822 disabling Simple-V-Ext) or implicitly (detect the case all-vlens=1,
1823 all-simd-bitwidths=default) switch OFF any decoding, perhaps even to
1824 the extreme of skipping an entire pipeline stage (if one is needed)
1825 * whether packed bitwidth and associated regfile splitting is so complex
1826 that it should definitely, definitely be made mandatory that implementors
1827 move regfile splitting into the ALU, and what are the implications of that
1828 * whether even if that *is* made mandatory, is software-trapped
1829 "unsupported bitwidths" still desirable, on the basis that SIMD is such
1830 a complete nightmare that *even* having a software implementation is
1831 better, making Simple-V have more in common with a software API than
1834 Whilst the above may seem to be severe minuses, there are some strong
1837 * Significant reduction of V's opcode space: over 95%.
1838 * Smaller reduction of P's opcode space: around 10%.
1839 * The potential to use Compressed instructions in both Vector and SIMD
1840 due to the overloading of register meaning (implicit vectorisation,
1842 * Not only present but also future extensions automatically gain parallelism.
1843 * Already mentioned but worth emphasising: the simplification to compiler
1844 writers and assembly-level writers of having the same consistent ISA
1845 regardless of whether the internal level of parallelism (number of
1846 parallel ALUs) is only equal to one ("virtual" parallelism), or is
1847 greater than one, should not be underestimated.
1849 ## Reducing Register Bank porting
1851 This looks quite reasonable.
1852 <https://www.princeton.edu/~rblee/ELE572Papers/MultiBankRegFile_ISCA2000.pdf>
1854 The main details are outlined on page 4. They propose a 2-level register
1855 cache hierarchy, note that registers are typically only read once, that
1856 you never write back from upper to lower cache level but always go in a
1857 cycle lower -> upper -> ALU -> lower, and at the top of page 5 propose
1858 a scheme where you look ahead by only 2 instructions to determine which
1859 registers to bring into the cache.
1861 The nice thing about a vector architecture is that you *know* that
1862 *even more* registers are going to be pulled in: Hwacha uses this fact
1863 to optimise L1/L2 cache-line usage (avoid thrashing), strangely enough
1864 by *introducing* deliberate latency into the execution phase.
1866 ## Overflow registers in combination with predication
1868 **TODO**: propose overflow registers be actually one of the integer regs
1869 (flowing to multiple regs).
1871 **TODO**: propose "mask" (predication) registers likewise. combination with
1872 standard RV instructions and overflow registers extremely powerful, see
1875 When integer overflow is stored in an easily-accessible bit (or another
1876 register), parallelisation turns this into a group of bits which can
1877 potentially be interacted with in predication, in interesting and powerful
1878 ways. For example, by taking the integer-overflow result as a predication
1879 field and shifting it by one, a predicated vectorised "add one" can emulate
1880 "carry" on arbitrary (unlimited) length addition.
1882 However despite RVV having made room for floating-point exceptions, neither
1883 RVV nor base RV have taken integer-overflow (carry) into account, which
1884 makes proposing it quite challenging given that the relevant (Base) RV
1885 sections are frozen. Consequently it makes sense to forgo this feature.
1887 ## Context Switch Example <a name="context_switch"></a>
1889 An unusual side-effect of Simple-V mapping onto the standard register files
1890 is that LOAD-multiple and STORE-multiple are accidentally available, as long
1891 as it is acceptable that the register(s) to be loaded/stored are contiguous
1892 (per instruction). An additional accidental benefit is that Compressed LD/ST
1895 To illustrate how this works, here is some example code from FreeRTOS
1896 (GPLv2 licensed, portasm.S):
1898 /* Macro for saving task context */
1899 .macro portSAVE_CONTEXT
1900 .global pxCurrentTCB
1901 /* make room in stack */
1902 addi sp, sp, -REGBYTES * 32
1906 STORE x2, 1 * REGBYTES(sp)
1907 STORE x3, 2 * REGBYTES(sp)
1910 STORE x30, 29 * REGBYTES(sp)
1911 STORE x31, 30 * REGBYTES(sp)
1913 /* Store current stackpointer in task control block (TCB) */
1914 LOAD t0, pxCurrentTCB //pointer
1918 /* Saves current error program counter (EPC) as task program counter */
1921 STORE t0, 31 * REGBYTES(sp)
1924 /* Saves current return adress (RA) as task program counter */
1926 STORE ra, 31 * REGBYTES(sp)
1929 /* Macro for restoring task context */
1930 .macro portRESTORE_CONTEXT
1932 .global pxCurrentTCB
1933 /* Load stack pointer from the current TCB */
1934 LOAD sp, pxCurrentTCB
1937 /* Load task program counter */
1938 LOAD t0, 31 * REGBYTES(sp)
1941 /* Run in machine mode */
1945 /* Restore registers,
1946 Skip global pointer because that does not change */
1948 LOAD x4, 3 * REGBYTES(sp)
1949 LOAD x5, 4 * REGBYTES(sp)
1952 LOAD x30, 29 * REGBYTES(sp)
1953 LOAD x31, 30 * REGBYTES(sp)
1955 addi sp, sp, REGBYTES * 32
1959 The important bits are the Load / Save context, which may be replaced
1960 with firstly setting up the Vectors and secondly using a *single* STORE
1961 (or LOAD) including using C.ST or C.LD, to indicate that the entire
1962 bank of registers is to be loaded/saved:
1964 /* a few things are assumed here: (a) that when switching to
1965 M-Mode an entirely different set of CSRs is used from that
1966 which is used in U-Mode and (b) that the M-Mode x1 and x4
1967 vectors are also not used anywhere else in M-Mode, consequently
1968 only need to be set up just the once.
1971 MVECTORCSRx1 = 31, defaultlen
1972 MVECTORCSRx4 = 28, defaultlen
1975 SETVL x0, x0, 31 /* x0 ignored silently */
1976 STORE x1, 0x0(sp) // x1 marked as 31-long vector of default bitwidth
1978 /* Restore registers,
1979 Skip global pointer because that does not change */
1981 SETVL x0, x0, 28 /* x0 ignored silently */
1982 LOAD x4, 3 * REGBYTES(sp) // x4 marked as 28-long default bitwidth
1984 Note that although it may just be a bug in portasm.S, x2 and x3 appear not
1985 to be being restored. If however this is a bug and they *do* need to be
1986 restored, then the SETVL call may be moved to *outside* the Save / Restore
1987 Context assembly code, into the macroVectorSetup, as long as vectors are
1988 never used anywhere else (i.e. VL is never altered by M-Mode).
1990 In effect the entire bank of repeated LOAD / STORE instructions is replaced
1991 by one single (compressed if it is available) instruction.
1993 ## Virtual Memory page-faults on LOAD/STORE
1996 ### Notes from conversations
1998 > I was going through the C.LOAD / C.STORE section 12.3 of V2.3-Draft
1999 > riscv-isa-manual in order to work out how to re-map RVV onto the standard
2000 > ISA, and came across an interesting comments at the bottom of pages 75
2003 > " A common mechanism used in other ISAs to further reduce save/restore
2004 > code size is load- multiple and store-multiple instructions. "
2006 > Fascinatingly, due to Simple-V proposing to use the *standard* register
2007 > file, both C.LOAD / C.STORE *and* LOAD / STORE would in effect be exactly
2008 > that: load-multiple and store-multiple instructions. Which brings us
2009 > on to this comment:
2011 > "For virtual memory systems, some data accesses could be resident in
2012 > physical memory and
2013 > some could not, which requires a new restart mechanism for partially
2014 > executed instructions."
2016 > Which then of course brings us to the interesting question: how does RVV
2017 > cope with the scenario when, particularly with LD.X (Indexed / indirect
2018 > loads), part-way through the loading a page fault occurs?
2020 > Has this been noted or discussed before?
2022 For applications-class platforms, the RVV exception model is
2023 element-precise (that is, if an exception occurs on element j of a
2024 vector instruction, elements 0..j-1 have completed execution and elements
2025 j+1..vl-1 have not executed).
2027 Certain classes of embedded platforms where exceptions are always fatal
2028 might choose to offer resumable/swappable interrupts but not precise
2032 > Is RVV designed in any way to be re-entrant?
2037 > What would the implications be for instructions that were in a FIFO at
2038 > the time, in out-of-order and VLIW implementations, where partial decode
2041 The usual bag of tricks for maintaining precise exceptions applies to
2042 vector machines as well. Register renaming makes the job easier, and
2043 it's relatively cheaper for vectors, since the control cost is amortized
2044 over longer registers.
2047 > Would it be reasonable at least to say *bypass* (and freeze) the
2048 > instruction FIFO (drop down to a single-issue execution model temporarily)
2049 > for the purposes of executing the instructions in the interrupt (whilst
2050 > setting up the VM page), then re-continue the instruction with all
2053 This approach has been done successfully, but it's desirable to be
2054 able to swap out the vector unit state to support context switches on
2055 exceptions that result in long-latency I/O.
2058 > Or would it be better to switch to an entirely separate secondary
2059 > hyperthread context?
2061 > Does anyone have any ideas or know if there is any academic literature
2062 > on solutions to this problem?
2064 The Vector VAX offered imprecise but restartable and swappable exceptions:
2065 http://mprc.pku.edu.cn/~liuxianhua/chn/corpus/Notes/articles/isca/1990/VAX%20vector%20architecture.pdf
2067 Sec. 4.6 of Krste's dissertation assesses some of
2068 the tradeoffs and references a bunch of related work:
2069 http://people.eecs.berkeley.edu/~krste/thesis.pdf
2074 Started reading section 4.6 of Krste's thesis, noted the "IEE85 F.P
2075 exceptions" and thought, "hmmm that could go into a CSR, must re-read
2076 the section on FP state CSRs in RVV 0.4-Draft again" then i suddenly
2077 thought, "ah ha! what if the memory exceptions were, instead of having
2078 an immediate exception thrown, were simply stored in a type of predication
2079 bit-field with a flag "error this element failed"?
2081 Then, *after* the vector load (or store, or even operation) was
2082 performed, you could *then* raise an exception, at which point it
2083 would be possible (yes in software... I know....) to go "hmmm, these
2084 indexed operations didn't work, let's get them into memory by triggering
2085 page-loads", then *re-run the entire instruction* but this time with a
2086 "memory-predication CSR" that stops the already-performed operations
2087 (whether they be loads, stores or an arithmetic / FP operation) from
2088 being carried out a second time.
2090 This theoretically could end up being done multiple times in an SMP
2091 environment, and also for LD.X there would be the remote outside annoying
2092 possibility that the indexed memory address could end up being modified.
2094 The advantage would be that the order of execution need not be
2095 sequential, which potentially could have some big advantages.
2096 Am still thinking through the implications as any dependent operations
2097 (particularly ones already decoded and moved into the execution FIFO)
2098 would still be there (and stalled). hmmm.
2102 > > # assume internal parallelism of 8 and MAXVECTORLEN of 8
2107 > > x3[1]: exception
2113 > > what happens to result elements 2-7? those may be *big* results
2115 > > or in the RVV-Extended may be arbitrary bit-widths far greater.
2121 discussion then led to the question of OoO architectures
2123 > The costs of the imprecise-exception model are greater than the benefit.
2124 > Software doesn't want to cope with it. It's hard to debug. You can't
2125 > migrate state between different microarchitectures--unless you force all
2126 > implementations to support the same imprecise-exception model, which would
2127 > greatly limit implementation flexibility. (Less important, but still
2128 > relevant, is that the imprecise model increases the size of the context
2129 > structure, as the microarchitectural guts have to be spilled to memory.)
2131 ## Zero/Non-zero Predication
2133 >> > it just occurred to me that there's another reason why the data
2134 >> > should be left instead of zeroed. if the standard register file is
2135 >> > used, such that vectorised operations are translated to mean "please
2136 >> > insert multiple register-contiguous operations into the instruction
2137 >> > FIFO" and predication is used to *skip* some of those, then if the
2138 >> > next "vector" operation uses the (standard) registers that were masked
2139 >> > *out* of the previous operation it may proceed without blocking.
2141 >> > if however zeroing is made mandatory then that optimisation becomes
2142 >> > flat-out impossible to deploy.
2144 >> > whilst i haven't fully thought through the full implications, i
2145 >> > suspect RVV might also be able to benefit by being able to fit more
2146 >> > overlapping operations into the available SRAM by doing something
2150 > Luke, this is called density time masking. It doesn’t apply to only your
2151 > model with the “standard register file” is used. it applies to any
2152 > architecture that attempts to speed up by skipping computation and writeback
2153 > of masked elements.
2155 > That said, the writing of zeros need not be explicit. It is possible to add
2156 > a “zero bit” per element that, when set, forces a zero to be read from the
2157 > vector (although the underlying storage may have old data). In this case,
2158 > there may be a way to implement DTM as well.
2161 ## Implementation detail for scalar-only op detection <a name="scalar_detection"></a>
2163 Note 1: this idea is a pipeline-bypass concept, which may *or may not* be
2166 Note 2: this is just one possible implementation. Another implementation
2167 may choose to treat *all* operations as vectorised (including treating
2168 scalars as vectors of length 1), choosing to add an extra pipeline stage
2169 dedicated to *all* instructions.
2171 This section *specifically* covers the implementor's freedom to choose
2172 that they wish to minimise disruption to an existing design by detecting
2173 "scalar-only operations", bypassing the vectorisation phase (which may
2174 or may not require an additional pipeline stage)
2176 [[scalardetect.png]]
2178 >> For scalar ops an implementation may choose to compare 2-3 bits through an
2179 >> AND gate: are src & dest scalar? Yep, ok send straight to ALU (or instr
2182 > Those bits cannot be known until after the registers are decoded from the
2183 > instruction and a lookup in the "vector length table" has completed.
2184 > Considering that one of the reasons RISC-V keeps registers in invariant
2185 > positions across all instructions is to simplify register decoding, I expect
2186 > that inserting an SRAM read would lengthen the critical path in most
2191 > briefly: the trick i mentioned about ANDing bits together to check if
2192 > an op was fully-scalar or not was to be read out of a single 32-bit
2193 > 3R1W SRAM (64-bit if FPU exists). the 32/64-bit SRAM contains 1 bit per
2194 > register indicating "is register vectorised yes no". 3R because you need
2195 > to check src1, src2 and dest simultaneously. the entries are *generated*
2196 > from the CSRs and are an optimisation that on slower embedded systems
2197 > would likely not be needed.
2199 > is there anything unreasonable that anyone can foresee about that?
2200 > what are the down-sides?
2202 ## C.MV predicated src, predicated dest
2204 > Can this be usefully defined in such a way that it is
2205 > equivalent to vector gather-scatter on each source, followed by a
2206 > non-predicated vector-compare, followed by vector gather-scatter on the
2209 ## element width conversion: restrict or remove?
2211 summary: don't restrict / remove. it's fine.
2213 > > it has virtually no cost/overhead as long as you specify
2214 > > that inputs can only upconvert, and operations are always done at the
2215 > > largest size, and downconversion only happens at the output.
2217 > okaaay. so that's a really good piece of implementation advice.
2218 > algorithms do require data size conversion, so at some point you need to
2219 > introduce the feature of upconverting and downconverting.
2221 > > for int and uint, this is dead simple and fits well within the RVV pipeline
2222 > > without any critical path, pipeline depth, or area implications.
2224 <https://groups.google.com/a/groups.riscv.org/forum/#!topic/isa-dev/g3feFnAoKIM>
2226 ## Under review / discussion: remove CSR vector length, use VSETVL <a name="vsetvl"></a>
2228 **DECISION: 11jun2018 - CSR vector length removed, VSETVL determines
2229 length on all regs**. This section kept for historical reasons.
2231 So the issue is as follows:
2233 * CSRs are used to set the "span" of a vector (how many of the standard
2234 register file to contiguously use)
2235 * VSETVL in RVV works as follows: it sets the vector length (copy of which
2236 is placed in a dest register), and if the "required" length is longer
2237 than the *available* length, the dest reg is set to the MIN of those
2239 * **HOWEVER**... in SV, *EVERY* vector register has its own separate
2240 length and thus there is no way (at the time that VSETVL is called) to
2241 know what to set the vector length *to*.
2242 * At first glance it seems that it would be perfectly fine to just limit
2243 the vector operation to the length specified in the destination
2244 register's CSR, at the time that each instruction is issued...
2245 except that that cannot possibly be guaranteed to match
2246 with the value *already loaded into the target register from VSETVL*.
2248 Therefore a different approach is needed.
2250 Possible options include:
2252 * Removing the CSR "Vector Length" and always using the value from
2253 VSETVL. "VSETVL destreg, counterreg, #lenimmed" will set VL *and*
2254 destreg equal to MIN(counterreg, lenimmed), with register-based
2255 variant "VSETVL destreg, counterreg, lenreg" doing the same.
2256 * Keeping the CSR "Vector Length" and having the lenreg version have
2257 a "twist": "if lengreg is vectorised, read the length from the CSR"
2260 The first option (of the ones brainstormed so far) is a lot simpler.
2261 It does however mean that the length set in VSETVL will apply across-the-board
2262 to all src1, src2 and dest vectorised registers until it is otherwise changed
2263 (by another VSETVL call). This is probably desirable behaviour.
2265 ## Implementation Paradigms <a name="implementation_paradigms"></a>
2267 TODO: assess various implementation paradigms. These are listed roughly
2268 in order of simplicity (minimum compliance, for ultra-light-weight
2269 embedded systems or to reduce design complexity and the burden of
2270 design implementation and compliance, in non-critical areas), right the
2271 way to high-performance systems.
2273 * Full (or partial) software-emulated (via traps): full support for CSRs
2274 required, however when a register is used that is detected (in hardware)
2275 to be vectorised, an exception is thrown.
2276 * Single-issue In-order, reduced pipeline depth (traditional SIMD / DSP)
2277 * In-order 5+ stage pipelines with instruction FIFOs and mild register-renaming
2278 * Out-of-order with instruction FIFOs and aggressive register-renaming
2281 Also to be taken into consideration:
2283 * "Virtual" vectorisation: single-issue loop, no internal ALU parallelism
2284 * Comphrensive vectorisation: FIFOs and internal parallelism
2285 * Hybrid Parallelism
2287 ### Full or partial software-emulation
2289 The absolute, absolute minimal implementation is to provide the full
2290 set of CSRs and detection logic for when any of the source or destination
2291 registers are vectorised. On detection, a trap is thrown, whether it's
2292 a branch, LOAD, STORE, or an arithmetic operation.
2294 Implementors are entirely free to choose whether to allow absolutely every
2295 single operation to be software-emulated, or whether to provide some emulation
2296 and some hardware support. In particular, for an RV32E implementation
2297 where fast context-switching is a requirement (see "Context Switch Example"),
2298 it makes no sense to allow Vectorised-LOAD/STORE to be implemented as an
2299 exception, as every context-switch will result in double-traps.
2303 > For great floating point DSPs check TI’s C3x, C4X, and C6xx DSPs
2305 Idea: basic simple butterfly swap on a few element indices, primarily targetted
2306 at SIMD / DSP. High-byte low-byte swapping, high-word low-word swapping,
2307 perhaps allow reindexing of permutations up to 4 elements? 8? Reason:
2308 such operations are less costly than a full indexed-shuffle, which requires
2309 a separate instruction cycle.
2311 Predication "all zeros" needs to be "leave alone". Detection of
2312 ADD r1, rs1, rs0 cases result in nop on predication index 0, whereas
2313 ADD r0, rs1, rs2 is actually a desirable copy from r2 into r0.
2314 Destruction of destination indices requires a copy of the entire vector
2315 in advance to avoid.
2317 TBD: floating-point compare and other exception handling
2321 * SIMD considered harmful <https://www.sigarch.org/simd-instructions-considered-harmful/>
2322 * Link to first proposal <https://groups.google.com/a/groups.riscv.org/forum/#!topic/isa-dev/GuukrSjgBH8>
2323 * Recommendation by Jacob Bachmeyer to make zero-overhead loop an
2324 "implicit program-counter" <https://groups.google.com/a/groups.riscv.org/d/msg/isa-dev/vYVi95gF2Mo/SHz6a4_lAgAJ>
2325 * Re-continuing P-Extension proposal <https://groups.google.com/a/groups.riscv.org/forum/#!msg/isa-dev/IkLkQn3HvXQ/SEMyC9IlAgAJ>
2326 * First Draft P-SIMD (DSP) proposal <https://groups.google.com/a/groups.riscv.org/forum/#!topic/isa-dev/vYVi95gF2Mo>
2327 * B-Extension discussion <https://groups.google.com/a/groups.riscv.org/forum/#!topic/isa-dev/zi_7B15kj6s>
2328 * Broadcom VideoCore-IV <https://docs.broadcom.com/docs/12358545>
2329 Figure 2 P17 and Section 3 on P16.
2330 * Hwacha <https://www2.eecs.berkeley.edu/Pubs/TechRpts/2015/EECS-2015-262.html>
2331 * Hwacha <https://www2.eecs.berkeley.edu/Pubs/TechRpts/2015/EECS-2015-263.html>
2332 * Vector Workshop <http://riscv.org/wp-content/uploads/2015/06/riscv-vector-workshop-june2015.pdf>
2333 * Predication <https://groups.google.com/a/groups.riscv.org/forum/#!topic/isa-dev/XoP4BfYSLXA>
2334 * Branch Divergence <https://jbush001.github.io/2014/12/07/branch-divergence-in-parallel-kernels.html>
2335 * Life of Triangles (3D) <https://jbush001.github.io/2016/02/27/life-of-triangle.html>
2336 * Videocore-IV <https://github.com/hermanhermitage/videocoreiv/wiki/VideoCore-IV-3d-Graphics-Pipeline>
2337 * Discussion proposing CSRs that change ISA definition
2338 <https://groups.google.com/a/groups.riscv.org/forum/#!topic/isa-dev/InzQ1wr_3Ak>
2339 * Zero-overhead loops <https://pdfs.semanticscholar.org/dbaa/66985cc730d4b44d79f519e96ec9c43ab5b7.pdf>
2340 * Multi-ported VLIW Register File Implementation <https://ce-publications.et.tudelft.nl/publications/1517_multiple_contexts_in_a_multiported_vliw_register_file_impl.pdf>
2341 * Fast context save/restore proposal <https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/57F823FA.6030701%40gmail.com>
2342 * Register File Bank Cacheing <https://www.princeton.edu/~rblee/ELE572Papers/MultiBankRegFile_ISCA2000.pdf>
2343 * Expired Patent on Vector Virtual Memory solutions
2344 <https://patentimages.storage.googleapis.com/fc/f6/e2/2cbee92fcd8743/US5895501.pdf>
2345 * Discussion on RVV "re-entrant" capabilities allowing operations to be
2346 restarted if an exception occurs (VM page-table miss)
2347 <https://groups.google.com/a/groups.riscv.org/d/msg/isa-dev/IuNFitTw9fM/CCKBUlzsAAAJ>
2348 * Dot Product Vector <https://people.eecs.berkeley.edu/~biancolin/papers/arith17.pdf>
2349 * RVV slides 2017 <https://content.riscv.org/wp-content/uploads/2017/12/Wed-1330-RISCVRogerEspasaVEXT-v4.pdf>
2350 * Wavefront skipping using BRAMS <http://www.ece.ubc.ca/~lemieux/publications/severance-fpga2015.pdf>
2351 * Streaming Pipelines <http://www.ece.ubc.ca/~lemieux/publications/severance-fpga2014.pdf>
2352 * Barcelona SIMD Presentation <https://content.riscv.org/wp-content/uploads/2018/05/09.05.2018-9.15-9.30am-RISCV201805-Andes-proposed-P-extension.pdf>
2353 * <http://www.ece.ubc.ca/~lemieux/publications/severance-fpga2015.pdf>
2354 * Full Description (last page) of RVV instructions
2355 <https://inst.eecs.berkeley.edu/~cs152/sp18/handouts/lab4-1.0.pdf>