\section{Summary}
Simple-V is a Scalable Vector Specification for a hardware for-loop that
ONLY uses scalar instructions.

\begin{itemize}
\item The Power ISA v3.1 Specification is not altered in any way.
  v3.1 Code-compatibility is guaranteed.
\item Does not require sacrificing 32-bit Major Opcodes.
\item Specifically designed to be easily implemented
  on top of an existing Micro-architecture (especially
  Superscalar Out-of-Order Multi-issue) without
  disruptive full architectural redesigns.
\item Divided into Compliancy Levels to suit differing needs.
\item At the highest Compliancy Level only requires five instructions
  (SVE2 requires appx 9,000. AVX-512 around 10,000. RVV around
  300).
\item Predication, an often-requested feature, is added cleanly
  (without modifying the v3.1 Power ISA)
\item In-registers arbitrary-sized Matrix Multiply is achieved in three
  instructions (without adding any v3.1 Power ISA instructions)
\item Full DCT and FFT RADIX2 Triple-loops are achieved with dramatically
  reduced instruction count, and power consumption expected to greatly
  reduce. Normally found only in high-end VLIW DSPs (TI MSP, Qualcomm
  Hexagon)
\item Fail-First Load/Store allows strncpy to be implemented in around 14
  instructions (hand-optimised VSX assembler is 240).
\item Inner loop of MP3 implemented in under 100 instructions
  (gcc produces 450 for the same function)
\end{itemize}

All areas investigated so far consistently showed reductions in executable
size, which as outlined in \cite{SIMD_HARM} has an indirect reduction in
power consumption due to less I-Cache/TLB pressure and also Issue remaining
idle for long periods.

\pagebreak

\subsection{What is SIMD?}
\textit{(for clarity only 64-bit registers will be discussed here,
       however 128-, 256-, and 512-bit implementations also exist)}

\ac{SIMD} is a way of partitioning existing \ac{CPU}
registers of 64-bit length into smaller 8-, 16-, 32-bit pieces
\cite{SIMD_HARM}\cite{SIMD_HPC}. These partitions can then be operated
on simultaneously, and the initial values and results being stored as
entire 64-bit registers. The SIMD instruction opcode includes the data
width and the operation to perform.\par

\begin{figure}[h]
	\includegraphics[width=\linewidth]{simd_axb}
	\caption{SIMD multiplication}
	\label{fig:simd_axb}
\end{figure}

This method can have a huge advantage for rapid processing of
vector-type data (image/video, physics simulations, cryptography,
etc.)\cite{SIMD_WASM}, and thus on paper is very attractive compared to
scalar-only instructions.\par

SIMD registers are of a fixed length and thus to achieve greater
performance, CPU architects typically increase the width of registers
(to 128-, 256-, 512-bit etc) for more partitions.\par Additionally,
binary compatibility is an important feature, and thus each doubling
of SIMD registers also expands the instruction set. The number of
instructions quickly balloons and this can be seen in popular \ac{ISA},
for example IA-32 expanding from 80 to about 1400 instructions since
1978\cite{SIMD_HARM}.\par

\subsection{Vector Architectures}
An older alternative exists to utilise data parallelism - vector
architectures. Vector CPUs collect operands from the main memory, and
store them in large, sequential vector registers.\par

A simple vector processor might operate on one element at a time,
however as the element operations are usually independent,
a processor could be made to compute all of the vector's
elements simultaneously, taking advantage of multiple pipelines.\par

Typically, today's vector processors can execute two, four, or eight
64-bit elements per clock cycle\cite{SIMD_HARM}. Such processors can also
deal with (in hardware) fringe cases where the vector length is not a
multiple of the number of elements. The element data width is variable
(just like in SIMD). Fig \ref{fig:vl_reg_n} shows the relationship
between number of elements, data width and register vector length.

\begin{figure}[h]
	\includegraphics[width=\linewidth]{vl_reg_n}
	\caption{Vector length, data width, number of elements}
	\label{fig:vl_reg_n}
\end{figure}

RISC-V Vector extension supports a VL of up to $2^{16}$ or $65536$ bits,
which can fit 1024 64-bit words \cite{riscv-v-spec}.

\subsection{Comparison Between SIMD and Vector}
\textit{(Need to add more here, use example from \cite{SIMD_HARM}?)}

\subsubsection{Code Example}
\begin{verbatim}
test test
\end{verbatim}

\subsection{Shortfalls of SIMD}
Five digit Opcode proliferation (10,000 instructions) is overwhelming.
The following are just some of the reasons why SIMD is unsustainable as
the number of instructions increase:
\begin{itemize}
	\item Hardware design, ASIC routing etc.
	\item Compiler design
	\item Documentation of the ISA
	\item Manual coding and optimisation
	\item Time to support the platform
\end{itemize}

\subsection{Simple Vectorisation}
\ac{SV} is a Scalable Vector ISA designed for hybrid workloads (CPU, GPU,
VPU, 3D?).  Includes features normally found only on Cray-style Supercomputers
(Cray-1, NEC SX-Aurora) and GPUs.  Keeps to a strict uniform RISC paradigm,
leveraging a scalar ISA by using "Prefixing".
\textbf{No dedicated vector opcodes exist in SV, at all}.

\vspace{10pt}
Main design principles
\begin{itemize}
	\item Introduce by implementing on top of existing Power ISA
	\item Effectively a \textbf{hardware for-loop}, pauses main PC,
	      issues multiple scalar op's
	\item Preserves underlying scalar execution dependencies as
	      the for-loop had been expanded as actual scalar instructions
        ("preserving Program Order")
	\item Augments existing instructions by adding "tags" - provides
          Vectorisation "context" rather than adding new opcodes.
	\item Does not modify or deviate from the underlying scalar
          Power ISA unless there's a significant performance boost or other
          advantage in the vector space (see \ref{subsubsec:add_to_pow_isa})
	\item Aimed at Supercomputing: avoids creating significant
	      \textit{sequential dependency hazards}, allowing \textbf{high
	      performance superscalar microarchitectures} to be deployed.
\end{itemize}

Advantages include:
\begin{itemize}
	\item Easy to create first (and sometimes only) implementation
	      as a literal for-loop in hardware, simulators, and compilers.
	\item Hardware Architects may understand and implement SV as
          being an extra pipeline stage, inserted between decode and
          issue. Essentially a simple for-loop issuing element-level
          sub-instructions.
	\item More complex HDL can be done by repeating existing scalar
	      ALUs and pipelines as blocks, leveraging existing Multi-Issue
          Infrastructure.
	\item Mostly high-level "context" which does not significantly
          deviate from scalar Power ISA and, in its purest form
          being a "for-loop around scalar instructions". Thus SV is
          minimally-disruptive and consequently has a reasonable chance
          of broad community adoption and acceptance.
	\item Obliterates SIMD opcode proliferation
          ($O(N^6)$) as well as dedicated Vectorisation
          ISAs. No more separate vector instructions.
\end{itemize}

\subsubsection{Prefix 64 - SVP64}

SVP64, is a specification designed to solve the problems caused by
SIMD implementations by:
\begin{itemize}
	\item Simplifying the hardware design
	\item Reducing maintenance overhead
	\item Reducing code size and power consumption
	\item Easier for compilers, coders, documentation
	\item Time to support platform is a fraction of conventional SIMD
	      (Less money on R\&D, faster to deliver)
\end{itemize}

- Intel SIMD has been incrementally added to for decades, requires backwards
  interoperability, and thus has a greater complexity (?)


- What are we going to gain?

-for loop, increment registers RT, RA, RB
-few instructions, easier to implement and maintain
-example assembly code
-ARM has already started to add to libC SVE2 support

1970 x86 comparison
