\section{Spear2}
Die Spear2-Architektur wurde an der TU-Wien entwickelt und versuchte dadurch ein relativ einfaches
Design ohne Lizenzkosten verf\"ugbar zu machen. Daher f\"allt der Kern der Architektur
relativ simple als RISC-Architektur aus.
\subsection{Einsatzgebiet}
Die Spear2-Architektur beschreibt einen Softcore-Prozessor, d.h. dieser kann den eigenen Bed\"urfnissen
angepasst werden. Einerseits kann zwischen einer 16/32-Bit Architektur gew\"ahlt werden, andererseits besteht
die M\"oglichkeit eigene oder dritte Module an den internen oder AMBA-Bus anzuschlie\ss en. Somit sind
viele der in der GRLIB enthaltenen Module kompatibel.
Der Grund warum ARM heutzutage in vielen ES eingesetzt wird, besteht in der Flexibilit\"at. Oftmals
werden einfach nicht viele I/O-Pins oder eben Rechenleistung ben\"otigt, wie sie Hardcore-Architekturen
anbieten. Hier versucht sich die Spear2-Architektur ebenfalls einzureihen. Somit bleibt dem
Entwickler die Wahl, welchen Algorithmus er in Hardware und welchen Software implementieren m\"ochte.
\subsection{Conditional Instructions und Jumps}
Alle Abh\"angigkeiten werden von der Hardware \"uberpr\"uft und entsprechend behandelt. D.h.
im ISA-Level m\"ussen keine Abh\"angigkeiten ber\"ucksichtigt werden. Im Falle von CI wird entweder
ein \texttt{NOP} eingef\"ugt (bzw. Ctrl-Signale deaktiviert) oder die Instruktion wird normal behandelt.
Alle Conditional- und Jump Tests passiern in der Decode-Stufe und die eigentliche Ausf\"uhrung wird in der Exec-Stage
abgeschlossen, wobei Ctrl-Signale an die Decode-Stufe zur\"uckgef\"uhrt werden. Es wurden keine
Stalls oder \"ahnliches eingef\"uhrt, damit die Programm Execution einer Instruktion konstant bleibt.
\subsection{Ziele}
Das Ziel dieser Architektur besteht darin eine gro\ss e Flexibilit\"at zu bieten. Dadurch kann die Spear2-Architektur
dem Einsatzgebiet angepasst werden. D.h. falls notwendig kann z.B. ein FFT oder eine Multiplikation der Architektur
hinzugef\"ugt werden um mehr Performance zu erreichen. Falls Schnittstellen an die Umgebung fehlen, k\"onnen
diese als Erweiterungsmodule implementiert werden. Somit kann der Spear2 relativ klein gehalten werden (Cost, Performance)
und eine h\"ohere Taktrate erzielen als eine Hardcore-Architektur. Au\ss erdem ist SW leichter zu warten und verstehen, dies
wiederrum verk\"urzt die Entwicklungszeit. Dennoch wird ein Fixedfunction-Core bessere Ergebnisse erzielen, wenn sich
die Funktionalit\"at des Softcore-Prozessors nicht mehr von diesem unterscheidet.
Da aber die ISA relativ begrenzt ist (\texttt{add}, \texttt{sub}, \texttt{comp},
\texttt{load}, \texttt{store},...), wird die Programmgr\"o\ss e (fixed OP-Code) nat\"urlich
bei komplexen Operationen wachsen. Dennoch ist der OP-Code mit 16-Bit relativ klein.

Damit auf Extension-Module oder Speicher schnell zugegriffen werden kann (Stackoperation), gibt es sogenannte Framepointer.
Dieser l\"adt ein Wort von der dort hinterlegten Adresse und z\"ahlt ein Offset hinzu. Somit k\"onnen wortweise Zugriffe
innerhalb von einem Zyklus erfolgen.
\subsection{W\"unsche}
Prinzipiell ist diese ISA eine sehr kompakte und elegante Form einer RISC-Architektur, dennoch w\"are z.B. ein dedizierter Stackpointer
w\"unschenswert gewesen, da bei verschachtelten Subroutine-Calls die Software die R\"ucksprungadresse speichern muss. F\"ur
einen stack\"ahnlichen Betrieb kann nat\"urlich ein Framepointer herangezogen werden. Dennoch w\"achst dadurch der Code.
\subsection{Listing}
Register \texttt{r14} wird f\"ur die R\"ucksprungadresse verwendet, \texttt{r0} f\"ur den R\"uckgabewert und \texttt{r1-r4} f\"ur die Argumente.
\texttt{r5-r8} wird f\"ur tempor\"are Register verwendet (Caller-Save).
\begin{lstlisting}[caption=Spear2 Code]{Spear2-Code}
ldli r0, 0    #sum=0
ldli r5,-20   #Framepointer X
ldli r6, 0    #i=0
stw r2, r5    #fpx -> &arr[0]

cmp_eq r1, r6 #for
jmpi_ct, 4    #i<len

ldfpx r7,0    #arr[i]
add r0, r7    #sum+=arr[i]
addi r6, 1    #i++

jmpi -5       #for end
rts
\end{lstlisting}
Man erkennt, dass innerhalb der Schleife sechs Instruktionen ausgef\"uhrt werden (inkl. Bedingungen). Ein Jump bewirkt
einen Flush in der Decode-Stufe. Also wird \texttt{jump} zu einem
\texttt{jump+nop}. Solange die Schleife exekutiert wird, ergibt sich eine
Laufzeit von sieben Zyklen, bei sechs Befehlen was einer Codesize des Loops von 12 Bytes entspricht.
