\section{Spear2}\r
Die Spear2-Architektur wurde an der TU-Wien entwickelt und versuchte dadurch ein relativ einfaches\r
-Design ohne Lizenzkosten verfügbar zu machen. Daher fällt der Kern der Architektur\r
+Design ohne Lizenzkosten verf\"ugbar zu machen. Daher f\"allt der Kern der Architektur\r
relativ simple als RISC-Architektur aus.\r
\subsection{Einsatzgebiet}\r
-Die Spear2-Architektur beschreibt einen Softcore-Prozessor, d.h. dieser kann den eigenen Bedürfnissen\r
-angepasst werden. Einerseits kann zwischen einer 16/32-Bit Architektur gewählt werden, andererseits besteht\r
-die Möglichkeit eigene oder dritte Module an den internen oder AMBA-Bus anzuschließen. Somit sind\r
+Die Spear2-Architektur beschreibt einen Softcore-Prozessor, d.h. dieser kann den eigenen Bed\"urfnissen\r
+angepasst werden. Einerseits kann zwischen einer 16/32-Bit Architektur gew\"ahlt werden, andererseits besteht\r
+die M\"oglichkeit eigene oder dritte Module an den internen oder AMBA-Bus anzuschlie\ss en. Somit sind\r
viele der in der GRLIB enthaltenen Module kompatibel.\r
-Der Grund warum ARM heutzutage in vielen ES eingesetzt wird, besteht in der Flexibilität. Oftmals\r
-werden einfach nicht viele I/O-Pins oder eben rechenleistung benötigt, wie sie Hardcore-Architekturen\r
+Der Grund warum ARM heutzutage in vielen ES eingesetzt wird, besteht in der Flexibilit\"at. Oftmals\r
+werden einfach nicht viele I/O-Pins oder eben Rechenleistung ben\"otigt, wie sie Hardcore-Architekturen\r
anbieten. Hier versucht sich die Spear2-Architektur ebenfalls einzureihen. Somit bleibt dem\r
-Entwickler die Wahl, welchen Algorithmus er in Hardware und welchen Software implementieren möchte.\r
+Entwickler die Wahl, welchen Algorithmus er in Hardware und welchen Software implementieren m\"ochte.\r
\subsection{Conditional Instructions und Jumps}\r
-Alle Abhängigkeiten werden von der Hardware überprüft und entsprechend behandelt. D.h.\r
-im ISA-Level müssen keine Abhängigkeiten berücksichtigt werden. Im Falle von CI wird entweder\r
-ein NOP-eingefügt (bzw. Ctrl-Signale deaktiviert) oder die Instruktion wird normal behandelt.\r
-Alle Conditional- und Jump Tests passiern in der Decode-Stufe und die eigentliche Ausführung wird in der Exec-Stage\r
-abgeschlossen, wobei Ctrl-Signale an die Decode-Stufe zurückgeführt werden. Es wurden keine\r
-Stalls oder ähnliches eingeführt, damit die Programm Execution\r
+Alle Abh\"angigkeiten werden von der Hardware \"uberpr\"uft und entsprechend behandelt. D.h.\r
+im ISA-Level m\"ussen keine Abh\"angigkeiten ber\"ucksichtigt werden. Im Falle von CI wird entweder\r
+ein NOP-eingef\"ugt (bzw. Ctrl-Signale deaktiviert) oder die Instruktion wird normal behandelt.\r
+Alle Conditional- und Jump Tests passiern in der Decode-Stufe und die eigentliche Ausf\"uhrung wird in der Exec-Stage\r
+abgeschlossen, wobei Ctrl-Signale an die Decode-Stufe zur\"uckgef\"uhrt werden. Es wurden keine\r
+Stalls oder \"ahnliches eingef\"uhrt, damit die Programm Execution einer Instruktion konstant bleibt.\r
\subsection{Ziele}\r
-Das Ziel dieser Architektur besteht darin eine große Flexibilität zu bieten. Dadurch kann die Spear2-Architektur\r
+Das Ziel dieser Architektur besteht darin eine gro\ss e Flexibilit\"at zu bieten. Dadurch kann die Spear2-Architektur\r
dem Einsatzgebiet angepasst werden. D.h. falls notwendig kann z.B. ein FFT oder eine Multiplikation der Architektur\r
-hinzugefügt werden um mehr Performance zu erreichen. Falls Schnittstellen an die Umgebung fehlen, können\r
+hinzugef\"ugt werden um mehr Performance zu erreichen. Falls Schnittstellen an die Umgebung fehlen, k\"onnen\r
diese als Erweiterungsmodule implementiert werden. Somit kann der Spear2 relativ klein gehalten werden (Cost, Performance)\r
-und eine höhere Taktrate erzielen als eine Hardcore-Architektur. Außerdem ist SW leichter zu warten und verstehen, dies\r
-wiederrum verkürzt die Etwicklungszeit. Dennoch wird ein Fixedfunction-Core bessere Ergebnisse erzielen, wenn sich\r
-die Funktionalität des Softcore-Prozessors nicht mehr von diesem unterscheidet.\r
-Da aber die ISA relativ begrenzt ist (add, sub, comp, load, store,...), wird die Programmgröße (fixed OP-Code) natürlich\r
+und eine h\"ohere Taktrate erzielen als eine Hardcore-Architektur. Au\ss erdem ist SW leichter zu warten und verstehen, dies\r
+wiederrum verk\"urzt die Entwicklungszeit. Dennoch wird ein Fixedfunction-Core bessere Ergebnisse erzielen, wenn sich\r
+die Funktionalit\"at des Softcore-Prozessors nicht mehr von diesem unterscheidet.\r
+Da aber die ISA relativ begrenzt ist (add, sub, comp, load, store,...), wird die Programmgr\"o\ss e (fixed OP-Code) nat\"urlich\r
bei komplexen Operationen wachsen. Dennoch ist der OP-Code mit 16-Bit relativ klein.\r
\r
Damit auf Extension-Module oder Speicher schnell zugegriffen werden kann (Stackoperation), gibt es sogenannte Framepointer.\r
-Dieser lädt ein Wort von der dort hinterlegten Adresse und zählt ein Offset hinzu. Somit können wortweise Zugriffe\r
+Dieser l\"adt ein Wort von der dort hinterlegten Adresse und z\"ahlt ein Offset hinzu. Somit k\"onnen wortweise Zugriffe\r
innerhalb von einem Zyklus erfolgen.\r
-\subsection{Wünsche}\r
-Prinzipiell ist diese ISA eine sehr kompakte und elegante Form einer RISC-Architektur, dennoch wäre z.B. ein dedizierter Stackpointer\r
-wünschenswert gewesen, da bei verschachtelten Subroutine-Calls die Software die Rücksprungadresse speichern muss. Für\r
-einen Stackähnlichen Betrieb kann natürlich ein Framepointer herangezogen werden. Dennoch wächst dadurch der Code.\r
+\subsection{W\"unsche}\r
+Prinzipiell ist diese ISA eine sehr kompakte und elegante Form einer RISC-Architektur, dennoch w\"are z.B. ein dedizierter Stackpointer\r
+w\"unschenswert gewesen, da bei verschachtelten Subroutine-Calls die Software die R\"ucksprungadresse speichern muss. F\"ur\r
+einen stack\"ahnlichen Betrieb kann nat\"urlich ein Framepointer herangezogen werden. Dennoch w\"achst dadurch der Code.\r
\subsection{Listing}\r
-Register r14 wird für die Rücksprungadresse verwendet, r0 für den Rückgabewert und r1-r4 für die Argumente.\r
-r5-r8 wird für temporäre Register verwendet (Caller-Save).\r
+Register r14 wird f\"ur die R\"ucksprungadresse verwendet, r0 f\"ur den R\"uckgabewert und r1-r4 f\"ur die Argumente.\r
+r5-r8 wird f\"ur tempor\"are Register verwendet (Caller-Save).\r
\begin{lstlisting}[caption=Spear2 Code]{Spear2-Code}\r
ldli r0, 0 #sum=0\r
ldli r5,-20 #Framepointer X\r
jmpi -5 #for end\r
rts\r
\end{lstlisting}\r
-Man erkennt, dass innerhalb der Schleife 6 Instruktionen ausgeführt werden (inkl. Bedingungen). Ein Jump bewirkt\r
-einen Flush in der Decode-Stufe. Also wird jump zu einem jump+nop. Also solange die Schleife exekutiert wird, ergibt sich eine\r
+Man erkennt, dass innerhalb der Schleife 6 Instruktionen ausgef\"uhrt werden (inkl. Bedingungen). Ein Jump bewirkt\r
+einen Flush in der Decode-Stufe. Also wird jump zu einem jump+nop. Solange die Schleife exekutiert wird, ergibt sich eine\r
Laufzeit von 7 Zyklen, bei 6 Befehlen was einer Codesize des Loops von 12 Bytes entspricht.\r
projects / calu.git / blobdiff