\frame{\frametitle{Quick refresher on SIMD}
\begin{itemize}
- \item SIMD very easy to implement (and very seductive)\vspace{10pt}
- \item Parallelism is in the ALU\vspace{10pt}
- \item Zero-to-Negligeable impact for rest of core\vspace{10pt}
+ \item SIMD very easy to implement (and very seductive)\vspace{8pt}
+ \item Parallelism is in the ALU\vspace{8pt}
+ \item Zero-to-Negligeable impact for rest of core\vspace{8pt}
\end{itemize}
Where SIMD Goes Wrong:\vspace{10pt}
\begin{itemize}
\item See "SIMD instructions considered harmful"
- https://www.sigarch.org/simd-instructions-considered-harmful
- \item Corner-cases alone are extremely complex.\\
+ https://sigarch.org/simd-instructions-considered-harmful
+ \item Setup and corner-cases alone are extremely complex.\\
Hardware is easy, but software is hell.
\item O($N^{6}$) ISA opcode proliferation!\\
opcode, elwidth, veclen, src1-src2-dest hi/lo
\begin{itemize}
\item Extremely powerful (extensible to 256 registers)\vspace{10pt}
\item Supports polymorphism, several datatypes (inc. FP16)\vspace{10pt}
- \item Requires a separate Register File (32 w/ext to 256)\vspace{10pt}
+ \item Requires a separate Register File (16 w/ext to 256)\vspace{10pt}
\item Implemented as a separate pipeline (no impact on scalar)\vspace{10pt}
\end{itemize}
However...\vspace{10pt}
\begin{itemize}
\item 98 percent opcode duplication with rest of RV (CLIP)
\item Extending RVV requires customisation not just of h/w:\\
- gcc and s/w also need customisation (and maintenance)
+ gcc, binutils also need customisation (and maintenance)
\end{itemize}
}
on [contiguous] blocks of registers, in parallel.\vspace{4pt}
\item What?
Simple-V is an "API" that implicitly extends
- existing (scalar) instructions with explicit parallelisation
+ existing (scalar) instructions with explicit parallelisation\\
(i.e. SV is actually about parallelism NOT vectors per se)
\end{itemize}
}
\item Greatly-reduced I-cache load (and less reads)
\item Amazingly, SIMD becomes (more) tolerable\\
(corner-cases for setup and teardown are gone)
+ \item Modularity/Abstraction in both the h/w and the toolchain.
\end{itemize}
Note:
\begin{itemize}
\begin{itemize}
\item A full supercomputer-level Vector Proposal
\item A replacement for RVV (SV is designed to be over-ridden\\
- by - or augmented to become, or just be replaced by - RVV)
+ by - or augmented to become - RVV)
\end{itemize}
}
\item Standard Register File(s) overloaded with CSR "reg is vector"\\
(see pseudocode slides for examples)
\item Element width (and type?) concepts remain same as RVV\\
- (CSRs are used to "interpret" elements in registers)
+ (CSRs give new size (and meaning?) to elements in registers)
\item CSRs are key-value tables (overlaps allowed)\vspace{10pt}
\end{itemize}
Key differences from RVV:\vspace{10pt}
s2 = reg\_is\_vectorised(src2);
if (!s2 && !s1) goto branch;
for (int i = 0; i < VL; ++i)
- if cmp(s1 ? reg[src1+i] : reg[src1],
- s2 ? reg[src2+i] : reg[src2])
- preg[rs3] |= 1 << i;
+ if (cmp(s1 ? reg[src1+i]:reg[src1],
+ s2 ? reg[src2+i]:reg[src2])
+ ireg[rs3] |= 1<<i;
\end{semiverbatim}
\begin{itemize}
}
+\begin{frame}[fragile]
+\frametitle{Example c code: DAXPY}
+
+\begin{semiverbatim}
+ void daxpy(size_t n, double a,
+ const double x[], double y[])
+ \{
+ for (size_t i = 0; i < n; i++) \{
+ y[i] = a*x[i] + y[i];
+ \}
+ \}
+\end{semiverbatim}
+
+ \begin{itemize}
+ \item See "SIMD Considered Harmful" for SIMD/RVV analysis\\
+ https://sigarch.org/simd-instructions-considered-harmful/
+ \end{itemize}
+
+
+\end{frame}
+
+
+\begin{frame}[fragile]
+\frametitle{RVV DAXPY assembly (RV32V)}
+
+\begin{semiverbatim}
+# a0 is n, a1 is ptr to x[0], a2 is ptr to y[0], fa0 is a
+ li t0, 2<<25
+ vsetdcfg t0 # enable 2 64b Fl.Pt. registers
+loop:
+ setvl t0, a0 # vl = t0 = min(mvl, n)
+ vld v0, a1 # load vector x
+ slli t1, t0, 3 # t1 = vl * 8 (in bytes)
+ vld v1, a2 # load vector y
+ add a1, a1, t1 # increment pointer to x by vl*8
+ vfmadd v1, v0, fa0, v1 # v1 += v0 * fa0 (y = a * x + y)
+ sub a0, a0, t0 # n -= vl (t0)
+ vst v1, a2 # store Y
+ add a2, a2, t1 # increment pointer to y by vl*8
+ bnez a0, loop # repeat if n != 0
+\end{semiverbatim}
+\end{frame}
+
+
+\begin{frame}[fragile]
+\frametitle{SV DAXPY assembly (RV64D)}
+
+\begin{semiverbatim}
+# a0 is n, a1 is ptr to x[0], a2 is ptr to y[0], fa0 is a
+ CSRvect1 = \{type: F, key: a3, val: a3, elwidth: dflt\}
+ CSRvect2 = \{type: F, key: a7, val: a7, elwidth: dflt\}
+loop:
+ setvl t0, a0, 4 # vl = t0 = min(4, n)
+ ld a3, a1 # load 4 registers a3-6 from x
+ slli t1, t0, 3 # t1 = vl * 8 (in bytes)
+ ld a7, a2 # load 4 registers a7-10 from y
+ add a1, a1, t1 # increment pointer to x by vl*8
+ fmadd a7, a3, fa0, a7 # v1 += v0 * fa0 (y = a * x + y)
+ sub a0, a0, t0 # n -= vl (t0)
+ st a7, a2 # store 4 registers a7-10 to y
+ add a2, a2, t1 # increment pointer to y by vl*8
+ bnez a0, loop # repeat if n != 0
+\end{semiverbatim}
+\end{frame}
+
+
\frame{\frametitle{Under consideration}
\begin{itemize}
\item Can VSELECT be removed? (it's really complex)
\item Can CLIP be done as a CSR (mode, like elwidth)
\item SIMD saturation (etc.) also set as a mode?
+ \item Include src1/src2 predication on Comparison Ops?\\
+ (same arrangement as C.MV, with same flexibility/power)
\item 8/16-bit ops is it worthwhile adding a "start offset"? \\
(a bit like misaligned addressing... for registers)\\
or just use predication to skip start?
\begin{itemize}
\item EVERY register operation is inherently parallelised\\
(scalar ops are just vectors of length 1)\vspace{4pt}
+ \item Tightly coupled with the core (instruction issue)\\
+ could be disabled through MISA switch\vspace{4pt}
\item An extra pipeline phase is pretty much essential\\
for fast low-latency implementations\vspace{4pt}
- \item Assuming an instruction FIFO, N ops could be taken off\\
- of a parallel op per cycle (avoids filling entire FIFO;\\
- also is less work per cycle: lower complexity / latency)\vspace{4pt}
\item With zeroing off, skipping non-predicated elements is hard:\\
it is however an optimisation (and could be skipped).\vspace{4pt}
\item Setting up the Register/Predication tables (interpreting the\\
}
-\frame{\frametitle{TODO (break into separate slides)}
-
- \begin{itemize}
- \item Then explain why this proposal is a good way to \\
- abstract parallelism\\
- (hopefully also explaining how \\
- a good compiler can make clever use of this increase parallelism\\
- Then explain how this can be implemented (at instruction\\
- issue time???) with\\
- implementation options, and what these "cost".\\
- Finally give examples that show simple usage that compares\\
- C code\\
- RVIC\\
- RVV\\
- RVICXsimplev
- \end{itemize}
-}
-
-
\frame{\frametitle{Summary}
\begin{itemize}
\item Actually about parallelism, not Vectors (or SIMD) per se
+ \item Only needs 3 actual instructions (plus CSRs)\\
+ RVV - and "standard" SIMD - require ISA duplication
\item Designed for flexibility (graded levels of complexity)
\item Huge range of implementor freedom
\item Fits RISC-V ethos: achieve more with less
}
-\frame{\frametitle{slide}
-
- \begin{itemize}
- \item \vspace{10pt}
- \end{itemize}
- Considerations:\vspace{10pt}
- \begin{itemize}
- \item \vspace{10pt}
- \end{itemize}
-}
-
-
\frame{
\begin{center}
{\Huge \red The end\vspace{20pt}\\
projects / libreriscv.git / blobdiff