1_isacmp/spear2.tex

   1 \section{Spear2}\r
   2 Die Spear2-Architektur wurde an der TU-Wien entwickelt und versuchte dadurch ein relativ einfaches\r
   3 Design ohne Lizenzkosten verf\"ugbar zu machen. Daher f\"allt der Kern der Architektur\r
   4 relativ simple als RISC-Architektur aus.\r
   5 \subsection{Einsatzgebiet}\r
   6 Die Spear2-Architektur beschreibt einen Softcore-Prozessor, d.h. dieser kann den eigenen Bed\"urfnissen\r
   7 angepasst werden. Einerseits kann zwischen einer 16/32-Bit Architektur gew\"ahlt werden, andererseits besteht\r
   8 die M\"oglichkeit eigene oder dritte Module an den internen oder AMBA-Bus anzuschlie\ss en. Somit sind\r
   9 viele der in der GRLIB enthaltenen Module kompatibel.\r
  10 Der Grund warum ARM heutzutage in vielen ES eingesetzt wird, besteht in der Flexibilit\"at. Oftmals\r
  11 werden einfach nicht viele I/O-Pins oder eben Rechenleistung ben\"otigt, wie sie Hardcore-Architekturen\r
  12 anbieten. Hier versucht sich die Spear2-Architektur ebenfalls einzureihen. Somit bleibt dem\r
  13 Entwickler die Wahl, welchen Algorithmus er in Hardware und welchen Software implementieren m\"ochte.\r
  14 \subsection{Conditional Instructions und Jumps}\r
  15 Alle Abh\"angigkeiten werden von der Hardware \"uberpr\"uft und entsprechend behandelt. D.h.\r
  16 im ISA-Level m\"ussen keine Abh\"angigkeiten ber\"ucksichtigt werden. Im Falle von CI wird entweder\r
  17 ein \texttt{NOP} eingef\"ugt (bzw. Ctrl-Signale deaktiviert) oder die Instruktion wird normal behandelt.\r
  18 Alle Conditional- und Jump Tests passiern in der Decode-Stufe und die eigentliche Ausf\"uhrung wird in der Exec-Stage\r
  19 abgeschlossen, wobei Ctrl-Signale an die Decode-Stufe zur\"uckgef\"uhrt werden. Es wurden keine\r
  20 Stalls oder \"ahnliches eingef\"uhrt, damit die Programm Execution einer Instruktion konstant bleibt.\r
  21 \subsection{Ziele}\r
  22 Das Ziel dieser Architektur besteht darin eine gro\ss e Flexibilit\"at zu bieten. Dadurch kann die Spear2-Architektur\r
  23 dem Einsatzgebiet angepasst werden. D.h. falls notwendig kann z.B. ein FFT oder eine Multiplikation der Architektur\r
  24 hinzugef\"ugt werden um mehr Performance zu erreichen. Falls Schnittstellen an die Umgebung fehlen, k\"onnen\r
  25 diese als Erweiterungsmodule implementiert werden. Somit kann der Spear2 relativ klein gehalten werden (Cost, Performance)\r
  26 und eine h\"ohere Taktrate erzielen als eine Hardcore-Architektur. Au\ss erdem ist SW leichter zu warten und verstehen, dies\r
  27 wiederrum verk\"urzt die Entwicklungszeit. Dennoch wird ein Fixedfunction-Core bessere Ergebnisse erzielen, wenn sich\r
  28 die Funktionalit\"at des Softcore-Prozessors nicht mehr von diesem unterscheidet.\r
  29 Da aber die ISA relativ begrenzt ist (\texttt{add}, \texttt{sub}, \texttt{comp},\r
  30 \texttt{load}, \texttt{store},...), wird die Programmgr\"o\ss e (fixed OP-Code) nat\"urlich\r
  31 bei komplexen Operationen wachsen. Dennoch ist der OP-Code mit 16-Bit relativ klein.\r
  32 \r
  33 Damit auf Extension-Module oder Speicher schnell zugegriffen werden kann (Stackoperation), gibt es sogenannte Framepointer.\r
  34 Dieser l\"adt ein Wort von der dort hinterlegten Adresse und z\"ahlt ein Offset hinzu. Somit k\"onnen wortweise Zugriffe\r
  35 innerhalb von einem Zyklus erfolgen.\r
  36 \subsection{W\"unsche}\r
  37 Prinzipiell ist diese ISA eine sehr kompakte und elegante Form einer RISC-Architektur, dennoch w\"are z.B. ein dedizierter Stackpointer\r
  38 w\"unschenswert gewesen, da bei verschachtelten Subroutine-Calls die Software die R\"ucksprungadresse speichern muss. F\"ur\r
  39 einen stack\"ahnlichen Betrieb kann nat\"urlich ein Framepointer herangezogen werden. Dennoch w\"achst dadurch der Code.\r
  40 \subsection{Listing}\r
  41 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.\r
  42 \texttt{r5-r8} wird f\"ur tempor\"are Register verwendet (Caller-Save).\r
  43 \begin{lstlisting}[caption=Spear2 Code]{Spear2-Code}\r
  44 ldli r0, 0    #sum=0\r
  45 ldli r5,-20   #Framepointer X\r
  46 ldli r6, 0    #i=0\r
  47 stw r2, r5    #fpx -> &arr[0]\r
  48 \r
  49 cmp_eq r1, r6 #for\r
  50 jmpi_ct, 4    #i<len\r
  51 \r
  52 ldfpx r7,0    #arr[i]\r
  53 add r0, r7    #sum+=arr[i]\r
  54 addi r6, 1    #i++\r
  55 \r
  56 jmpi -5       #for end\r
  57 rts\r
  58 \end{lstlisting}\r
  59 Man erkennt, dass innerhalb der Schleife sechs Instruktionen ausgef\"uhrt werden (inkl. Bedingungen). Ein Jump bewirkt\r
  60 einen Flush in der Decode-Stufe. Also wird \texttt{jump} zu einem\r
  61 \texttt{jump+nop}. Solange die Schleife exekutiert wird, ergibt sich eine\r
  62 Laufzeit von sieben Zyklen, bei sechs Befehlen was einer Codesize des Loops von 12 Bytes entspricht.\r