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ügbar zu machen. Daher fällt 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ürfnissen\r
   7 angepasst werden. Einerseits kann zwischen einer 16/32-Bit Architektur gewählt werden, andererseits besteht\r
   8 die Möglichkeit eigene oder dritte Module an den internen oder AMBA-Bus anzuschließ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ät. Oftmals\r
  11 werden einfach nicht viele I/O-Pins oder eben rechenleistung benötigt, 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öchte.\r
  14 \subsection{Conditional Instructions und Jumps}\r
  15 Alle Abhängigkeiten werden von der Hardware überprüft und entsprechend behandelt. D.h.\r
  16 im ISA-Level müssen keine Abhängigkeiten berücksichtigt werden. Im Falle von CI wird entweder\r
  17 ein NOP-eingefügt (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ührung wird in der Exec-Stage\r
  19 abgeschlossen, wobei Ctrl-Signale an die Decode-Stufe zurückgeführt werden. Es wurden keine\r
  20 Stalls oder ähnliches eingeführt, damit die Programm Execution\r
  21 \subsection{Ziele}\r
  22 Das Ziel dieser Architektur besteht darin eine große Flexibilität 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ügt werden um mehr Performance zu erreichen. Falls Schnittstellen an die Umgebung fehlen, können\r
  25 diese als Erweiterungsmodule implementiert werden. Somit kann der Spear2 relativ klein gehalten werden (Cost, Performance)\r
  26 und eine höhere Taktrate erzielen als eine Hardcore-Architektur. Außerdem ist SW leichter zu warten und verstehen, dies\r
  27 wiederrum verkürzt die Etwicklungszeit. Dennoch wird ein Fixedfunction-Core bessere Ergebnisse erzielen, wenn sich\r
  28 die Funktionalität des Softcore-Prozessors nicht mehr von diesem unterscheidet.\r
  29 Da aber die ISA relativ begrenzt ist (add, sub, comp, load, store,...), wird die Programmgröße (fixed OP-Code) natürlich\r
  30 bei komplexen Operationen wachsen. Dennoch ist der OP-Code mit 16-Bit relativ klein.\r
  31 \r
  32 Damit auf Extension-Module oder Speicher schnell zugegriffen werden kann (Stackoperation), gibt es sogenannte Framepointer.\r
  33 Dieser lädt ein Wort von der dort hinterlegten Adresse und zählt ein Offset hinzu. Somit können wortweise Zugriffe\r
  34 innerhalb von einem Zyklus erfolgen.\r
  35 \subsection{Wünsche}\r
  36 Prinzipiell ist diese ISA eine sehr kompakte und elegante Form einer RISC-Architektur, dennoch wäre z.B. ein dedizierter Stackpointer\r
  37 wünschenswert gewesen, da bei verschachtelten Subroutine-Calls die Software die Rücksprungadresse speichern muss. Für\r
  38 einen Stackähnlichen Betrieb kann natürlich ein Framepointer herangezogen werden. Dennoch wächst dadurch der Code.\r
  39 \subsection{Listing}\r
  40 Register r14 wird für die Rücksprungadresse verwendet, r0 für den Rückgabewert und r1-r4 für die Argumente.\r
  41 r5-r8 wird für temporäre Register verwendet (Caller-Save).\r
  42 \begin{lstlisting}[caption=Spear2 Code]{Spear2-Code}\r
  43 ldli r0, 0   #sum=0\r
  44 ldli r5,-20  #Framepointer X\r
  45 ldli r6, 0   #i=0\r
  46 stw r2, r5   #fpx -> &arr[0]\r
  47 \r
  48 cmp_eq r1, r6 #for\r
  49 jmpi_ct, 4    #i<len\r
  50 \r
  51 ldfpx r7,0   #arr[i]\r
  52 add r0, r7   #sum+=arr[i]\r
  53 addi r6, 1   #i++\r
  54 \r
  55 jmpi -5      #for end\r
  56 rts\r
  57 \end{lstlisting}\r
  58 Man erkennt, dass innerhalb der Schleife 6 Instruktionen ausgeführt werden (inkl. Bedingungen). Ein Jump bewirkt\r
  59 einen Flush in der Decode-Stufe. Also wird jump zu einem jump+nop. Also solange die Schleife exekutiert wird, ergibt sich eine\r
  60 Laufzeit von 7 Zyklen.\r