# Variable-width Variable-packed SIMD / Simple-V / Parallelism Extension Proposal
+[[!toc ]]
+
This proposal exists so as to be able to satisfy several disparate
requirements: power-conscious, area-conscious, and performance-conscious
designs all pull an ISA and its implementation in different conflicting
Additionally it makes sense to *split out* the parallelism inherent within
each of P and V, and to see if each of P and V then, in *combination* with
-a "best-of-both" parallelism extension, would work well.
+a "best-of-both" parallelism extension, could be added on *on top* of
+this proposal, to topologically provide the exact same functionality of
+each of P and V.
+
+Furthermore, an additional goal of this proposal is to reduce the number
+of opcodes utilised by each of P and V as they currently stand, leveraging
+existing RISC-V opcodes where possible, and also potentially allowing
+P and V to make use of Compressed Instructions as a result.
**TODO**: reword this to better suit this document:
**TODO**: propose "mask" (predication) registers likewise. combination with
standard RV instructions and overflow registers extremely powerful
+## CSRs marking registers as Vector
+
+A 32-bit CSR would be needed (1 bit per integer register) to indicate
+whether a register was, if referred to, implicitly to be treated as
+a vector.
+
+A second 32-bit CSR would be needed (1 bit per floating-point register)
+to indicate whether a floating-point register was to be treated as a
+vector.
+
+In this way any standard (current or future) operation involving
+register operands may detect if the operation is to be vector-vector,
+vector-scalar or scalar-scalar (standard) simply through a single
+bit test.
+
+## CSR vector-length and CSR SIMD packed-bitwidth
+
+**TODO** analyse each of these:
+
+* splitting out the loop-aspects, vector aspects and data-width aspects
+* integer reg 0 *and* fp reg0 share CSR vlen 0 *and* CSR packed-bitwidth 0
+* integer reg 1 *and* fp reg1 share CSR vlen 1 *and* CSR packed-bitwidth 1
+* ....
+* ....
+
+instead:
+
+* CSR vlen 0 *and* CSR packed-bitwidth 0 register contain extra bits
+ specifying an *INDEX* of WHICH int/fp register they refer to
+* CSR vlen 1 *and* CSR packed-bitwidth 1 register contain extra bits
+ specifying an *INDEX* of WHICH int/fp register they refer to
+* ...
+* ...
+
+Have to be very *very* careful about not implementing too few of those
+(or too many). Assess implementation impact on decode latency. Is it
+worth it?
+
+Implementation of the latter:
+
+Operation involving (referring to) register M:
+
+> bitwidth = default # default for opcode?
+> vectorlen = 1 # scalar
+>
+> for (o = 0, o < 2, o++)
+> if (CSR-Vector_registernum[o] == M)
+> bitwidth = CSR-Vector_bitwidth[o]
+> vectorlen = CSR-Vector_len[o]
+> break
+
+and for the former it would simply be:
+
+> bitwidth = CSR-Vector_bitwidth[M]
+> vectorlen = CSR-Vector_len[M]
+
+Alternatives:
+
+* One single "global" vector-length CSR
+
+## Stride
+
**TODO**: propose two LOAD/STORE offset CSRs, which mark a particular
register as being "if you use this reg in LOAD/STORE, use the offset
amount CSRoffsN (N=0,1) instead of treating LOAD/STORE as contiguous".
can be used for matrix spanning.
+> For LOAD/STORE, could a better option be to interpret the offset in the
+> opcode as a stride instead, so "LOAD t3, 12(t2)" would, if t3 is
+> configured as a length-4 vector base, result in t3 = *t2, t4 = *(t2+12),
+> t5 = *(t2+24), t6 = *(t2+32)? Perhaps include a bit in the
+> vector-control CSRs to select between offset-as-stride and unit-stride
+> memory accesses?
+
+So there would be an instruction like this:
+
+| SETOFF | On=rN | OBank={float|int} | Smode={offs|unit} | OFFn=rM |
+| opcode | 5 bit | 1 bit | 1 bit | 5 bit, OFFn=XLEN |
+
+
+which would mean:
+
+* CSR-Offset register n <= (float|int) register number N
+* CSR-Offset Stride-mode = offset or unit
+* CSR-Offset amount register n = contents of register M
+
+LOAD rN, ldoffs(rM) would then be (assuming packed bit-width not set):
+
+> offs = 0
+> stride = 1
+> vector-len = CSR-Vector-length register N
+>
+> for (o = 0, o < 2, o++)
+> if (CSR-Offset register o == M)
+> offs = CSR-Offset amount register o
+> if CSR-Offset Stride-mode == offset:
+> stride = ldoffs
+> break
+>
+> for (i = 0, i < vector-len; i++)
+> r[N+i] = mem[(offs*i + r[M+i])*stride]
# Analysis and discussion of Vector vs SIMD
This very simple proposal offers a way to increase pipeline activity in the
one key area which really matters: the inner loop.
-## Mask and Tagging
-
-*TODO: research masks as they can be superb and extremely powerful.
-If B-Extension is implemented and provides Bit-Gather-Scatter it
-becomes really cool and easy to switch out certain indexed values
-from an array of data, but actually BGS **on its own** might be
-sufficient. Bottom line, this is complex, and needs a proper analysis.
-The other sections are pretty straightforward.*
+## Mask and Tagging (Predication)
+
+Tagging (aka Masks aka Predication) is a pseudo-method of implementing
+simplistic branching in a parallel fashion, by allowing execution on
+elements of a vector to be switched on or off depending on the results
+of prior operations in the same array position.
+
+The reason for considering this is simple: by *definition* it
+is not possible to perform individual parallel branches in a SIMD
+(Single-Instruction, **Multiple**-Data) context. Branches (modifying
+of the Program Counter) will result in *all* parallel data having
+a different instruction executed on it: that's just the definition of
+SIMD, and it is simply unavoidable.
+
+So these are the ways in which conditional execution may be implemented:
+
+* explicit compare and branch: BNE x, y -> offs would jump offs
+ instructions if x was not equal to y
+* explicit store of tag condition: CMP x, y -> tagbit
+* implicit (condition-code) ADD results in a carry, carry bit implicitly
+ (or sometimes explicitly) goes into a "tag" (mask) register
+
+The first of these is a "normal" branch method, which is flat-out impossible
+to parallelise without look-ahead and effectively rewriting instructions.
+This would defeat the purpose of RISC.
+
+The latter two are where parallelism becomes easy to do without complexity:
+every operation is modified to be "conditionally executed" (in an explicit
+way directly in the instruction format *or* implicitly).
+
+RVV (Vector-Extension) proposes to have *explicit* storing of the compare
+in a tag/mask register, and to *explicitly* have every vector operation
+*require* that its operation be "predicated" on the bits within an
+explicitly-named tag/mask register.
+
+SIMD (P-Extension) has not yet published precise documentation on what its
+schema is to be: there is however verbal indication at the time of writing
+that:
+
+> The "compare" instructions in the DSP/SIMD ISA proposed by Andes will
+> be executed using the same compare ALU logic for the base ISA with some
+> minor modifications to handle smaller data types. The function will not
+> be duplicated.
+
+This is an *implicit* form of predication as the base RV ISA does not have
+condition-codes or predication. By adding a CSR it becomes possible
+to also tag certain registers as "predicated if referenced as a destination".
+Example:
+
+> # in future operations if r0 is the destination use r5 as
+> # the PREDICATION register
+> IMPLICICSRPREDICATE r0, r5
+> # store the compares in r5 as the PREDICATION register
+> CMPEQ8 r5, r1, r2
+> # r0 is used here. ah ha! that means it's predicated using r5!
+> ADD8 r0, r1, r3
+
+With enough registers (and there are enough registers) some fairly
+complex predication can be set up and yet still execute without significant
+stalling, even in a simple non-superscalar architecture.
+
+### Retro-fitting Predication into branch-explicit ISA
+
+One of the goals of this parallelism proposal is to avoid instruction
+duplication. However, with the base ISA having been designed explictly
+to *avoid* condition-codes entirely, shoe-horning predication into it
+bcomes quite challenging.
+
+However what if all branch instructions, if referencing a vectorised
+register, were instead given *completely new analogous meanings* that
+resulted in a parallel bit-wise predication register being set? This
+would have to be done for both C.BEQZ and C.BNEZ, as well as BEQ, BNE,
+BLT and BGE.
+
+We might imagine that FEQ, FLT and FLT would also need to be converted,
+however these are effectively *already* in the precise form needed and
+do not need to be converted *at all*! The difference is that FEQ, FLT
+and FLE *specifically* write a 1 to an integer register if the condition
+holds, and 0 if not. All that needs to be done here is to say, "if
+the integer register is tagged with a bit that says it is a predication
+register, the **bit** in the integer register is set based on the
+current vector index" instead.
+
+There is, in the standard Conditional Branch instruction, more than
+adequate space to interpret it in a similar fashion:
+
+[[!table data="""
+ 31 |30 ..... 25 |24 ... 20 | 19 ... 15 | 14 ...... 12 | 11 ....... 8 | 7 | 6 ....... 0 |
+imm[12] | imm[10:5] | rs2 | rs1 | funct3 | imm[4:1] | imm[11] | opcode |
+ 1 | 6 | 5 | 5 | 3 | 4 | 1 | 7 |
+ offset[12,10:5] || src2 | src1 | BEQ | offset[11,4:1] || BRANCH |
+"""]]
+
+This would become:
+
+[[!table data="""
+ 31 |30 ..... 25 |24 ... 20 | 19 ... 15 | 14 ...... 12 | 11 ....... 8 | 7 | 6 ....... 0 |
+imm[12] | imm[10:5] | rs2 | rs1 | funct3 | imm[4:1] | imm[11] | opcode |
+ 1 | 6 | 5 | 5 | 3 | 4 | 1 | 7 |
+ reserved || src2 | src1 | BEQ | predicate rs3 || BRANCH |
+"""]]
+
+Similarly the C.BEQZ and C.BNEZ instruction format may be retro-fitted,
+with the interesting side-effect that there is space within what is presently
+the "immediate offset" field to reinterpret that to add in not only a bit
+field to distinguish between floating-point compare and integer compare,
+not only to add in a second source register, but also use some of the bits as
+a predication target as well.
+
+[[!table data="""
+15 ...... 13 | 12 ........... 10 | 9..... 7 | 6 ................. 2 | 1 .. 0 |
+ funct3 | imm | rs10 | imm | op |
+ 3 | 3 | 3 | 5 | 2 |
+ C.BEQZ | offset[8|4:3] | src | offset[7:6|2:1|5] | C1 |
+"""]]
+
+Now uses the CS format:
+
+[[!table data="""
+15 ...... 13 | 12 ........... 10 | 9..... 7 | 6 .. 5 | 4......... 2 | 1 .. 0 |
+ funct3 | imm | rs10 | imm | | op |
+ 3 | 3 | 3 | 2 | 3 | 2 |
+ C.BEQZ | predicate rs3 | src1 | I/F B | src2 | C1 |
+"""]]
+
+Bit 6 would be decoded as "operation refers to Integer or Float"
+whilst Bit 5 would allow the operation to be decoded, in combination with
+funct3 = 110 or 111, a combination of four distinct comparison operators.
## Conclusions
-In the above sections the four different ways where parallel instruction
+In the above sections the five different ways where parallel instruction
execution has closely and loosely inter-related implications for the ISA and
for implementors, were outlined. The pluses and minuses came out as
follows:
* Implicit (indirect) vs fixed (integral) instruction bit-width: <b>indirect</b>
* Implicit vs explicit type-conversion: <b>explicit</b>
* Implicit vs explicit inner loops: <b>implicit</b>
-* Tag or no-tag: <b>TODO</b>
+* Tag or no-tag: <b>Complex and needs further thought</b>
In particular: variable-length vectors came out on top because of the
high setup, teardown and corner-cases associated with the fixed width
a Vector (varible-width SIM) may not precisely match the width of the
parallelism within the implementation, the end-user **should not care**
and in this way the performance benefits are gained but the ISA remains
-simple. All that happens at the end of an instruction run is: some
+straightforward. All that happens at the end of an instruction run is: some
parallel units (if there are any) would remain offline, completely
transparently to the ISA, the program, and the compiler.
The "SIMD considered harmful" trap of having huge complexity and extra
instructions to deal with corner-cases is thus avoided, and implementors
get to choose precisely where to focus and target the benefits of their
-implementationefforts..
+implementation efforts, without "extra baggage".
# V-Extension to Simple-V Comparative Analysis
wanting IEEE 704 FP Half-precision to end up somewhere in RISC-V in some
fashion, for optimising 3D Graphics. *sigh*.
+## TODO: analyse, auto-increment on unit-stride and constant-stride
+
+so i thought about that for a day or so, and wondered if it would be
+possible to propose a variant of zero-overhead loop that included
+auto-incrementing the two address registers a2 and a3, as well as
+providing a means to interact between the zero-overhead loop and the
+vsetvl instruction. a sort-of pseudo-assembly of that would look like:
+
+> # a2 to be auto-incremented by t0*4
+> zero-overhead-set-auto-increment a2, t0, 4
+> # a2 to be auto-incremented by t0*4
+> zero-overhead-set-auto-increment a3, t0, 4
+> zero-overhead-set-loop-terminator-condition a0 zero
+> zero-overhead-set-start-end stripmine, stripmine+endoffset
+> stripmine:
+> vsetvl t0,a0
+> vlw v0, a2
+> vlw v1, a3
+> vfma v1, a1, v0, v1
+> vsw v1, a3
+> sub a0, a0, t0
+>stripmine+endoffset:
+
+the question is: would something like this even be desirable? it's a
+variant of auto-increment [1]. last time i saw any hint of auto-increment
+register opcodes was in the 1980s... 68000 if i recall correctly... yep
+see [1]
+
+[1] http://fourier.eng.hmc.edu/e85_old/lectures/instruction/node6.html
+
+Reply:
+
+Another option for auto-increment is for vector-memory-access instructions
+to support post-increment addressing for unit-stride and constant-stride
+modes. This can be implemented by the scalar unit passing the operation
+to the vector unit while itself executing an appropriate multiply-and-add
+to produce the incremented address. This does *not* require additional
+ports on the scalar register file, unlike scalar post-increment addressing
+modes.
+
## TODO: instructions (based on Hwacha) V-Ext duplication analysis
This is partly speculative due to lack of access to an up-to-date
* Vector Indexed Memory Instructions (non-contiguous)
* Vector Atomic Memory Instructions.
-* Some of the Vector Arithmetic ops: MADD, MSUB,
- VSRL, VSRA, VEIDX, VFIRST, VSGNJN, VFSGNJX and potentially more.
+* Some of the Vector Misc ops: VEIDX, VFIRST, VCLASS, VPOPC
+ and potentially more.
* Consensual Jump
+Table of RV32V Instructions
+
+| RV32V | RV Equivalent (FP) | RV Equivalent (Int) |
+| ----- | --- | |
+| VADD | FADD | ADD |
+| VSUB | FSUB | SUB |
+| VSL | | |
+| VSR | | |
+| VAND | | AND |
+| VOR | | OR |
+| VXOR | | XOR |
+| VSEQ | | |
+| VSNE | | |
+| VSLT | | |
+| VSGE | | |
+| VCLIP | | |
+| VCVT | | |
+| VMPOP | | |
+| VMFIRST | | |
+| VEXTRACT | | |
+| VINSERT | | |
+| VMERGE | | |
+| VSELECT | | |
+| VSLIDE | | |
+| VDIV | FDIV | DIV |
+| VREM | | REM |
+| VMUL | FMUL | MUL |
+| VMULH | | |
+| VMIN | FMIN | |
+| VMAX | FMUX | |
+| VSGNJ | FSGNJ | |
+| VSGNJN | FSGNJN | |
+| VSGNJX | FSNGJX | |
+| VSQRT | FSQRT | |
+| VCLASS | | |
+| VPOPC | | |
+| VADDI | | |
+| VSLI | | |
+| VSRI | | |
+| VANDI | | |
+| VORI | | |
+| VXORI | | |
+| VCLIPI | | |
+| VMADD | FMADD | |
+| VMSUB | FMSUB | |
+| VNMADD | FNMSUB | |
+| VNMSUB | FNMADD | |
+| VLD | FLD | |
+| VLDS | | |
+| VLDX | | |
+| VST | FST | |
+| VSTS | | |
+| VSTX | | |
+| VAMOSWAP | | AMOSWAP |
+| VAMOADD | | AMOADD |
+| VAMOAND | | AMOAND |
+| VAMOOR | | AMOOR |
+| VAMOXOR | | AMOXOR |
+| VAMOMIN | | AMOMIN |
+| VAMOMAX | | AMOMAX |
+
## TODO: sort
> I suspect that the "hardware loop" in question is actually a zero-overhead
# P-Ext ISA
-| Mnemonic | 16-bit Instruction |
-| ------------------ | ------------------------- |
-| ADD16 rt, ra, rb | add |
-| RADD16 rt, ra, rb | Signed Halving add |
-| URADD16 rt, ra, rb | Unsigned Halving add |
-| KADD16 rt, ra, rb | Signed Saturating add |
-| UKADD16 rt, ra, rb | Unsigned Saturating add |
-| SUB16 rt, ra, rb | sub |
-| RSUB16 rt, ra, rb | Signed Halving sub |
+## 16-bit Arithmetic
+
+| Mnemonic | 16-bit Instruction | Simple-V Equivalent |
+| ------------------ | ------------------------- | ------------------- |
+| ADD16 rt, ra, rb | add | RV ADD (bitwidth=16) |
+| RADD16 rt, ra, rb | Signed Halving add | |
+| URADD16 rt, ra, rb | Unsigned Halving add | |
+| KADD16 rt, ra, rb | Signed Saturating add | |
+| UKADD16 rt, ra, rb | Unsigned Saturating add | |
+| SUB16 rt, ra, rb | sub | RV SUB (bitwidth=16) |
+| RSUB16 rt, ra, rb | Signed Halving sub | |
+| URSUB16 rt, ra, rb | Unsigned Halving sub | |
+| KSUB16 rt, ra, rb | Signed Saturating sub | |
+| UKSUB16 rt, ra, rb | Unsigned Saturating sub | |
+| CRAS16 rt, ra, rb | Cross Add & Sub | |
+| RCRAS16 rt, ra, rb | Signed Halving Cross Add & Sub | |
+| URCRAS16 rt, ra, rb| Unsigned Halving Cross Add & Sub | |
+| KCRAS16 rt, ra, rb | Signed Saturating Cross Add & Sub | |
+| UKCRAS16 rt, ra, rb| Unsigned Saturating Cross Add & Sub | |
+| CRSA16 rt, ra, rb | Cross Sub & Add | |
+| RCRSA16 rt, ra, rb | Signed Halving Cross Sub & Add | |
+| URCRSA16 rt, ra, rb| Unsigned Halving Cross Sub & Add | |
+| KCRSA16 rt, ra, rb | Signed Saturating Cross Sub & Add | |
+| UKCRSA16 rt, ra, rb| Unsigned Saturating Cross Sub & Add | |
+
+## 8-bit Arithmetic
+
+| Mnemonic | 16-bit Instruction | Simple-V Equivalent |
+| ------------------ | ------------------------- | ------------------- |
+| ADD8 rt, ra, rb | add | RV ADD (bitwidth=8)|
+| RADD8 rt, ra, rb | Signed Halving add | |
+| URADD8 rt, ra, rb | Unsigned Halving add | |
+| KADD8 rt, ra, rb | Signed Saturating add | |
+| UKADD8 rt, ra, rb | Unsigned Saturating add | |
+| SUB8 rt, ra, rb | sub | RV SUB (bitwidth=8)|
+| RSUB8 rt, ra, rb | Signed Halving sub | |
+| URSUB8 rt, ra, rb | Unsigned Halving sub | |
+
+# Exceptions
+
+> What does an ADD of two different-sized vectors do in simple-V?
+
+* if the two source operands are not the same, throw an exception.
+* if the destination operand is also a vector, and the source is longer
+ than the destination, throw an exception.
+
+> And what about instructions like JALR?
+> What does jumping to a vector do?
+
+* Throw an exception. Whether that actually results in spawning threads
+ as part of the trap-handling remains to be seen.
+
+# Impementing V on top of Simple-V
+
+* Number of Offset CSRs extends from 2
+* Extra register file: vector-file
+* Setup of Vector length and bitwidth CSRs now can specify vector-file
+ as well as integer or float file.
+* TODO
+
+# Implementing P (renamed to DSP) on top of Simple-V
+
+* Implementors indicate chosen bitwidth support in Vector-bitwidth CSR
+ (caveat: anything not specified drops through to software-emulation / traps)
+* TODO
+
+# Analysis of CSR decoding on latency
+
+<a name="csr_decoding_analysis"></a>
+
+It could indeed have been logically deduced (or expected), that there
+would be additional decode latency in this proposal, because if
+overloading the opcodes to have different meanings, there is guaranteed
+to be some state, some-where, directly related to registers.
+
+There are several cases:
+
+* All operands vector-length=1 (scalars), all operands
+ packed-bitwidth="default": instructions are passed through direct as if
+ Simple-V did not exist. Simple-V is, in effect, completely disabled.
+* At least one operand vector-length > 1, all operands
+ packed-bitwidth="default": any parallel vector ALUs placed on "alert",
+ virtual parallelism looping may be activated.
+* All operands vector-length=1 (scalars), at least one
+ operand packed-bitwidth != default: degenerate case of SIMD,
+ implementation-specific complexity here (packed decode before ALUs or
+ *IN* ALUs)
+* At least one operand vector-length > 1, at least one operand
+ packed-bitwidth != default: parallel vector ALUs (if any)
+ placed on "alert", virtual parallelsim looping may be activated,
+ implementation-specific SIMD complexity kicks in (packed decode before
+ ALUs or *IN* ALUs).
+
+Bear in mind that the proposal includes that the decision whether
+to parallelise in hardware or whether to virtual-parallelise (to
+dramatically simplify compilers and also not to run into the SIMD
+instruction proliferation nightmare) *or* a transprent combination
+of both, be done on a *per-operand basis*, so that implementors can
+specifically choose to create an application-optimised implementation
+that they believe (or know) will sell extremely well, without having
+"Extra Standards-Mandated Baggage" that would otherwise blow their area
+or power budget completely out the window.
+
+Additionally, two possible CSR schemes have been proposed, in order to
+greatly reduce CSR space:
+
+* per-register CSRs (vector-length and packed-bitwidth)
+* a smaller number of CSRs with the same information but with an *INDEX*
+ specifying WHICH register in one of three regfiles (vector, fp, int)
+ the length and bitwidth applies to.
+
+(See "CSR vector-length and CSR SIMD packed-bitwidth" section for details)
+
+In addition, LOAD/STORE has its own associated proposed CSRs that
+mirror the STRIDE (but not yet STRIDE-SEGMENT?) functionality of
+V (and Hwacha).
+
+Also bear in mind that, for reasons of simplicity for implementors,
+I was coming round to the idea of permitting implementors to choose
+exactly which bitwidths they would like to support in hardware and which
+to allow to fall through to software-trap emulation.
+
+So the question boils down to:
+
+* whether either (or both) of those two CSR schemes have significant
+ latency that could even potentially require an extra pipeline decode stage
+* whether there are implementations that can be thought of which do *not*
+ introduce significant latency
+* whether it is possible to explicitly (through quite simply
+ disabling Simple-V-Ext) or implicitly (detect the case all-vlens=1,
+ all-simd-bitwidths=default) switch OFF any decoding, perhaps even to
+ the extreme of skipping an entire pipeline stage (if one is needed)
+* whether packed bitwidth and associated regfile splitting is so complex
+ that it should definitely, definitely be made mandatory that implementors
+ move regfile splitting into the ALU, and what are the implications of that
+* whether even if that *is* made mandatory, is software-trapped
+ "unsupported bitwidths" still desirable, on the basis that SIMD is such
+ a complete nightmare that *even* having a software implementation is
+ better, making Simple-V have more in common with a software API than
+ anything else.
+
+Whilst the above may seem to be severe minuses, there are some strong
+pluses:
+
+* Significant reduction of V's opcode space: over 85%.
+* Smaller reduction of P's opcode space: around 10%.
+* The potential to use Compressed instructions in both Vector and SIMD
+ due to the overloading of register meaning (implicit vectorisation,
+ implicit packing)
+* Not only present but also future extensions automatically gain parallelism.
+* Already mentioned but worth emphasising: the simplification to compiler
+ writers and assembly-level writers of having the same consistent ISA
+ regardless of whether the internal level of parallelism (number of
+ parallel ALUs) is only equal to one ("virtual" parallelism), or is
+ greater than one, should not be underestimated.
# References
Figure 2 P17 and Section 3 on P16.
* Hwacha <https://www2.eecs.berkeley.edu/Pubs/TechRpts/2015/EECS-2015-262.html>
* Hwacha <https://www2.eecs.berkeley.edu/Pubs/TechRpts/2015/EECS-2015-263.html>
+* Vector Workshop <http://riscv.org/wp-content/uploads/2015/06/riscv-vector-workshop-june2015.pdf>
+* Predication <https://groups.google.com/a/groups.riscv.org/forum/#!topic/isa-dev/XoP4BfYSLXA>
+* Branch Divergence <https://jbush001.github.io/2014/12/07/branch-divergence-in-parallel-kernels.html>
+* Life of Triangles (3D) <https://jbush001.github.io/2016/02/27/life-of-triangle.html>
+* Videocore-IV <https://github.com/hermanhermitage/videocoreiv/wiki/VideoCore-IV-3d-Graphics-Pipeline>
projects / libreriscv.git / blobdiff