\section{MCS-51}
-Die MCS-51 Architektur wurde von Intel um 1980 entwickelt und wird, in \"ahnlicher Form, noch heute eingesetzt. Einer der bekanntesten Vertretter der Architektur ist der Intel 8051 Microkontroller. Heutzutage werden von verschiedensten Firmen Prozessoren angeboten, die ein ISA besitzen, welches mit dem MCS-51 kompatibel ist, jedoch ein schnelleres Instruktiontiminig bieten. Als Beispiel ist das CPI-51 von Silicon Laboratories zu nennen.
+Die MCS-51 Architektur wurde von Intel um 1980 entwickelt und wird, in \"ahnlicher Form, noch heute eingesetzt. Einer der bekanntesten Vertreter der Architektur ist der Intel 8051 Microkontroller. Heutzutage werden von verschiedensten Firmen Prozessoren angeboten, die ein ISA besitzen, welches mit dem MCS-51 kompatibel ist, jedoch ein schnelleres Instruktiontiminig bieten. Als Beispiel ist das CPI-51 von Silicon Laboratories zu nennen.
-Obwohl die MCS-51 eine 8-Bit Architektur ist, z\"ahlt sie zu den CISC Architektur \footnote{Wenn man RISC als Load-Store-Architektur definiert}, stellt eine Harvard-Architekur dar und ist eine Accumulator Maschine.
+Die MCS-51 ist eine Akkumulator Maschine, das ein 8-Bit Instruktionset besitzt, eine CISC Architektur hat und eine Harvard-Speicherarchitektur bietet.
\subsection{Einsatzgebiet}
-Trotz des Alters von MCS-51 werden kompatible Prozessoren noch immer verbaut. Durch die hohe Vielfalt an Endprodukten k\"onnen sie in vielen Gebieten eingesetzt werden, z.B. wenn ein geringer Stromverbrauch ben\"otigt wird und 8-Bit ausreichend sind. Der von Intel im ``MCS\copyright 51 Microcontroller Family User's Manual (1994)'' angegebene Einsatzzweck sind regelungstechnische Anwendungen.
+Trotz des Alters des MCS-51 werden kompatible Prozessoren noch immer verbaut. Durch die hohe Vielfalt an konkreten Prozessoren k\"onnen sie in vielen Gebieten eingesetzt werden, z.B. wenn ein geringer Stromverbrauch ben\"otigt wird und 8-Bit ausreichend sind. Der von Intel im ``MCS\copyright 51 Microcontroller Family User's Manual (1994)'' angegebene Einsatzzweck sind regelungstechnische Anwendungen.
\subsection{Conditional Jumps}
Conditional Jumps sind als Instruktionen vorhanden, jedoch in limitierten Umfang. Es sind nur (not) zero auf Bytes, Carry set auf das Statusbyte und Bit (not) set auf einige ausgew\"ahlte Bytes im RAM m\"oglich. Alle anderen Sprungtypen m\"ussen auf die vorhandenen Zur\"uckgef\"uhrt werden.
-Latenzen werden in Hardware behandelt und sind nicht auf dem ISA Level sichtbar. Es ist jedoch anzumerken das in der MCS-51 Architektur eine Unterscheidung zwischen Clocktakt und Maschinenzyklen zu machen ist. Eine Instruktion ben\"otigt f\"ur ihre Ausf\"uhrung mindestens einen Maschinenzyklus. Ein Maschinenzyklus wird in vier Teilbereiche unterteilt die denen einer \"ublichen Pipeline entsprechen und je 3 Clocktakte ben\"otigen. Dadurch entspricht eine Maschinenzyklus 12 Clocktakten.
-Diese Unterscheidung muss bei modernen Designs, wie dem CPI-51, nicht mehr gemacht werden. Diese besitzen schon eine vollst\"andige Pipeline wodurch gilt das ein Maschinenzyklus einem Clocktakt entspricht.
+Latenzen werden in Hardware behandelt und sind nicht auf dem ISA Level sichtbar. Es ist jedoch anzumerken das in der MCS-51 Architektur eine Unterscheidung zwischen Clocktakt und Maschinenzyklen zu machen ist. Eine Instruktion ben\"otigt f\"ur ihre Ausf\"uhrung mindestens einen Maschinenzyklus. Ein Maschinenzyklus wird in sechs Teilbereiche unterteilt, die \"ublichen Pipelinestages \"ahnlich sind, und je 6 Clocktakte ben\"otigen. Dadurch entspricht eine Maschinenzyklus 12 Clocktakten.
+Diese Unterscheidung muss bei modernen Designs, wie dem CPI-51, nicht mehr gemacht werden. Diese besitzen schon eine vollst\"andige Pipeline wodurch ein Maschinenzyklus einem Clocktakt entspricht.
\subsection{Ziele}
Als Ziel der Architektur ist das angegebene Einsatzgebiet (Regelungstechnik) zu sehen. Intel hebt dabei besonders die guten boolschen Operationen hervor, die auf Bitebene arbeiten k\"onnen.
\begin{itemize}
\item Teilweise Anwendung von boolschen Operatoren auf einzelne Bits
\item In der ISR-Vector Tabelle sind 8 Bytes f\"ur jeden Interrupt vorhanden, wodurch kleine ISR's direkt in dieser platziert werden k\"onnen.
- \item Es gibt 4 Registerbanken zu je 8 Registern die \"ueber das PSW \footnote{Program Status Word} ausgew\"ahlt werden k\"onnen.
+ \item Es gibt 4 Registerbanken zu je 8 Registern die \"uber das PSW \footnote{Program Status Word} ausgew\"ahlt werden k\"onnen.
\item Eine Division liefert Quotient und Rest.
- \item Die DJNZ-Operation \footnote{decrement jump not zero} ist bei Schleifen gut einsetzbar.
+ \item Die DJNZ-Operation \footnote{decrement jump not zero} ist bei Schleifen mit einem 8-Bit Counter gut einsetzbar.
\end{itemize}
Als etwas gew\"ohnungsbed\"urftig kann man folgende Features bezeichnen:
\item Es werden die Calling Conventions von SDCC verwendet
\end{itemize}
-Das Timing wurde f\"ur die Original MCS-51 Architektur ermittelt.
\lstinputlisting[caption=MCS-51 Code]{8051.s}
+Das Timing wurde f\"ur die Original MCS-51 Architektur ermittelt.
Es werden pro Schleifeniteration 21 Instruktionen ausgef\"uhrt. Dadurch ergibt sich eine Ausf\"uhrungszeit von 30$\mu$s (bei einer Clock von 12MHz) was 30 Maschinenzyklen beziehungsweise 360 Clocktakte entspricht. Die Codesize der Schleife ist 32 Bytes.
-Wenn man von 8-Bit Daten ausgehen w\"urde, h\"atte eine Schleifeniteration 5 Instruktionen, eine Ausf\"uhrungszeit von 8$\mu$s und eine Codesize von 6 Bytes. Es ist also sehr sch\"on zu sehen das Operationen mit 16-Bit Daten sehr teuer sind im vergleich zu 8-Bit Daten.
+Wenn man von 8-Bit Daten ausgehen w\"urde, h\"atte eine Schleifeniteration 5 Instruktionen, eine Ausf\"uhrungszeit von 8$\mu$s und eine Codesize von 6 Bytes. Es ist also sehr sch\"on zu sehen das Operationen mit 16-Bit Daten sehr teuer sind im Vergleich zu 8-Bit Daten.
SHELL := bash
-FILES = isa_cmp.tex 8051.tex 8051.s arm.tex avr.tex
-FILES += common.sty Makefile ppc.tex ppc.s spear2.tex cmp.tex
+FILES = isa_cmp.tex 8051.tex 8051.s arm.tex avr.tex common.sty
+FILES += Makefile ppc.tex ppc.s spear2.tex sum.c cmp.tex
TARGET = isa_cmp.pdf
PDFGEN = pdflatex --jobname=$(basename $@) $<
ARM wurde anfangs von der Firma ACORN entwickelt und steht f\"ur Advanced Risc Machine. Es existieren
mehrere verschiedene Versionen des Instruktionssatzes, diese Ausarbeitung gibt aber lediglich einen \"Uberblick
-\"uber die prizipiellen Konzepte der Architektur.
+\"uber die prinzipiellen Konzepte der Architektur.
\subsection{Einsatzgebiet}
Das 8-bit AVR Instruction Set ist das von den meisten Atmel Microkontroller implementierte Instructions Set.
Es ist eine RISC Architektur die vorallem auf 1 Zyklus Instructionen hin optimiert ist.
-Es handelt sich hierbei um eine Register basierende Maschiene.
+Es handelt sich hierbei um eine Register basierende Maschine.
\subsection{Einsatzgebiet}
Die 8-bit AVR ISA wird zum Beispiel in der megaAVR Serie verwendet, welche im Embedded Bereich eingesetzt wird. Sie bietet eine breite Auswahl aus Peripherie M\"oglichkeiten/Ger\"aten an. Dies macht sie verwendbar f\"ur eine breite Palette an Applicationen. Die Serie verf\"ugt unter anderem \"uber USB, LCD, CAN und LIN Interfaces, zus\"atzlich zu den Standards f\"ur SPI, UART oder I2C.
-Au\ss erdem bietet es Features wie Selbstprogrammierung des Flashes und damit sichere, g\"unstige Upgrades w\"ahrend des Betriebes an.
+Au\ss erdem bietet es Features wie die Selbstprogrammierung des Flashes und damit sichere, g\"unstige Upgrades w\"ahrend des Betriebes an.
\subsection{Conditional Jumps}
Conditional Jumps sind bei dieser ISA immer getrennt vorhanden.
Es gibt ein Set aus 3 Compare Instructionen, sowie eine Set f\"ur Branches.
-Durch die Compares werden im Statusregister Bit gesetzt bzw. gel\"oscht, welche dann von den einzelnen Branches abgefragt werden k\"onnen.
-Die Latenzzeiten die auftreten f\"ur Jumps und Branches, sowie f\"ur andere mehr Zyklen Instructionen werden auf Hardwareebene behandelt und sind deshalb nicht auf den ISA Level sichbar.
+Durch die Compares werden im Statusregister Bits gesetzt bzw. gel\"oscht, welche dann von den einzelnen Branches abgefragt werden k\"onnen.
+Die Latenzzeiten die bei Jumps und Branches, sowie bei anderen Instructionen mit mehreren Zyklen, auftreten werden auf Hardwareebene behandelt und sind deshalb nicht auf dem ISA Level sichtbar.
\subsection{Ziele}
Laut der ersten Feature Zeile in den AVR PDFs liegt das Hauptaugenmerk auf:
High-performance, Low-power
-Da die Komponenten haupts\"achlich im embedded Bereich eingesetzt werden ist klar, dass ein niedriger Energieverbrauch besonders wichtig ist.
+Da die Komponenten haupts\"achlich im Embedded Bereich eingesetzt werden ist klar, dass ein niedriger Energieverbrauch besonders wichtig ist.
Umgesetzt wird das ganze durch Instructionen die haupts\"achlich in einem Zyklus abgearbeitet werden.
Au\ss erdem werden bei den diversen Serien noch Sleep-Modi und andere Konzepte angeboten, die das Low-power Schema noch weiter unterst\"utzen.
Folgende zwei Punkte finde ich besonders positiv:
\begin{itemize}
\item Das getrennte Compare-Branch Konzept find ich sehr angenehm, da man die jeweiligen Optionen nach Wunsch kombinieren kann und es gibt auch gen\"ugend Branches
- so, dass man ziemlich alles was gebraucht wird abgedeckt ist.
+ so, dass ziemlich alles was gebraucht wird abgedeckt ist.
\item Das man viele Bitoperationen (auch Vergleiche f\"ur Conditional Jumps) zur Verf\"ugung hat.
\end{itemize}
Negativ auffallen ist mir:
\begin{itemize}
- \item Es gibt keinen add imidiate Befehl um eine Konstante zu einem Register hinzuzuf\"ugen.
+ \item Es gibt keinen add immediate Befehl um eine Konstante zu einem Register hinzuzuf\"ugen, jedoch um eine Konstante zu einem Word hinzuzuf\"ugen.
\end{itemize}
\subsection{Listing}
Ich gehe von folgenden Vorbedingungen aus:
\begin{itemize}
\item len in r24,r25
- \item Array im Datenspeicher unter Y+0:Y+1 bis Y+6:Y+7 abgelegt
+ \item Array liegt im Datenspeicher ab Y+0:Y+1
\item Summe wird in r24,r25 gespeichert
\end{itemize}
\section{Vergleich}
%``Hier vergleichen wir die verschiedene ISA's'' copyright <anonymus>\footnote{Markus Hofst\"atter}
Bis auf die MCS-51 Architektur sind alle Architekturen RISC und Registermaschinen, MCS-51 ist CISC und Akkumulator.
-Die L\"ange der Instruktionen ist bei ARM\footnote{Mit Ausnahme des Thumb-Modes, bei diesem sind es 16-Bit pro Instruktion} und PowerPC auf 32-Bit L\"ange fixiert, SPEAR2 auf 16-Bit, bei AVR und MCS-51 koennen die Instruktionen unterschiedliche L\"angen aufwei\ss en.
+Die L\"ange der Instruktionen ist bei ARM\footnote{Mit Ausnahme des Thumb-Modes, bei diesem sind es 16-Bit pro Instruktion} und PowerPC auf 32-Bit L\"ange fixiert, SPEAR2 auf 16-Bit, bei AVR und MCS-51 k\"onnen die Instruktionen eine unterschiedliche Anzahl von Bytes aufwei\ss en.
Bei AVR und SPEAR2 sind die meisten Instruktionen darauf ausgelegt in einem Zyklus abgearbeitet zu werden. Bei SPEAR2 ist es aber nicht garantiert das auch die Instruktionen ohne Verz\"ogerung ausgef\"uhrt werden (zum Beispiel dauert eine Instruktion nach einem Jump zwei Zyklen).
-Bei Conditional Operations reicht die Auswahl von sehr beschr\"ankt (MCS-51) bis zu fast alle Instruktionen (ARM).
+Bei Conditional Operations reicht die Anzahl und deren Umfang von sehr beschr\"ankt (MCS-51) bis zu fast alle Instruktionen (ARM).
Als Anwendungsgebiete kann man f\"ur alle Architekturen auf jedenfall Embedded Systems angeben. ARM und PowerPC sind auch im Desktop- und Serverbereich anzutreffen.
Die Instruktionsetgr\"o\ss e ist bei AVR und MCS-51, durch die 8-Bit bedingt, eher klein. SPEAR2 ist auch eher klein weil die urspr\"ungliche Architektur ebenfalls nur 8-Bit war. ARM und PowerPC haben, auch durch die 32-Bit L\"ange bedingt, ein gro\ss es Instruktionset.
-Das Sichern der R\"ucksprungadresse wird unterschiedlich gehandelt, AVR und MCS-51 sichern die Adresse automatisch auf den Stack. PowerPC, SPEAR2 und ARM sichern die R\"ucksprungadresse in ein Register.
-Codesize und Ausf\"uhrungszeit des Codest\"ucks \texttt{sum} sind in Tabelle \ref{cmp_tab} ersichtlich. Es ist ersichtlich das die Prozessoren mit h\"oherer Instruktionsl\"ange besser abschneiden wenn es um Codesize und Anzahl der Zyklen geht, was aber auch nicht verwundert. \\
+Das Sichern der R\"ucksprungadresse wird unterschiedlich gehandhabt. AVR und MCS-51 sichern die Adresse automatisch auf den Stack. PowerPC, SPEAR2 und ARM sichern die R\"ucksprungadresse in ein Register.
+Codesizes und Ausf\"uhrungszeiten des Codest\"ucks \texttt{sum} aus Listing~\ref{list:sum} sind in Tabelle~\ref{cmp_tab} ersichtlich. Es ist sofort ersichtlich das die Prozessoren mit h\"oherer Instruktionsl\"ange besser abschneiden wenn es um die Anzahl der Zyklen, und dadurch bedingt, um die Codesize geht, was aber auch nicht sehr verwunderlich ist.\\
-\begin{table}[h]
+\lstinputlisting[caption=Compute Sum, language=C, label=list:sum]{sum.c}
+
+\begin{table}[ht]
\begin{center}
\begin{tabular}{|l|c|c|c|c|c|}\hline
- Anzahl & AVR & ARM & PowerPC & MCS-51 & SPEAR2 \\ \hline
- Instruktionen & 9 & 4 & 3 & 21 & 6 \\ \hline
- Zyklen & 13/14 & 8 & 3 & 30 & 7 \\ \hline
- Bytes & 18 & 16 & 12 & 32 & 12 \\ \hline
+ Anzahl & ARM & AVR & MCS-51 & PowerPC & SPEAR2 \\ \hline
+ Instruktionen & 4 & 9 & 21 & 3 & 6 \\ \hline
+ Zyklen & 8 & 13/14 & 30 & 3 & 7 \\ \hline
+ Bytes & 16 & 18 & 32 & 12 & 12 \\ \hline
\end{tabular}
\caption{Vergleich der ISAs anhand der erfassten Kennwerte}
\label{cmp_tab}
\subsection{Beschreibung}
Bei den meisten Befehle der ISA handelt es sich um Register-zu-Register
-Operationen im Drei-Register Format. Jede Instruktion ist vier Byte gross.
-Durch Load bzw. Store Operationen besteht wie in jeder Load/Store-Architektur
+Operationen im Drei-Register Format. Jede Instruktion ist vier Byte gro\ss.
+Durch Load bzw. Store Operationen besteht, wie in jeder Load/Store-Architektur,
die M\"oglichkeit am Speicher zu operieren -- die Adressierungsarten sind
-hierbei \"ausserst eingeschr\"ankt: Zum Beispiel l\"adt die Instruktion
+hierbei \"au\ss erst eingeschr\"ankt: Zum Beispiel l\"adt die Instruktion
\mbox{\texttt{lwz r3,4(r1)}} den Inhalt an der Speicherstelle \texttt{r1+4} in
das Register \texttt{r3}. Weiters kann man die Basisadresse nach der
Speicheroperationen noch updaten, zum Beispiel: \texttt{stwu r3,4(r1)} speichert
den Inhalt von \texttt{r3} an die Speicherstelle \texttt{r1+4} und setzt weiters
\texttt{r1 := r1 + 4}.
-Typische Register plus Erkl\"arung die in einer PowerPC Implementierung
+Typische Register, plus Erkl\"arung, die in einer PowerPC Implementierung
vorhanden sind, findet man in Tabelle \ref{tab:ppcreg}.
\begin{table}[ht!]
\begin{tabular}{lp{3cm}p{9cm}}
rA,rS,SH,MB,ME}}, wobei \mbox{$0 \le \text{SH,MB,ME} \le 31$} gilt, nimmt den
Inhalt aus \texttt{rS} und rotiert diesen um \texttt{SH} nach links. Danach wird
auf das Ergebnis mit einer Maske verundet. Die angesprochene Maske ist 32-Bit
-gross und von der Stelle MB bis ME mit 1er und ansonsten 0er belegt. Sollte
-% TODO: gutes deutsches Wort?
-$\text{MB} > \text{ME}$ sein, so wird ``gewrappt''. Das Ergebnis wird in
-\texttt{rD} gespeichert.
+gro{\ss} und von der Stelle MB bis ME mit 1er und ansonsten 0er belegt. Sollte
+$\text{MB} > \text{ME}$ sein, so werden die Stellen ME bis MB mit 0er belegt
+und die anderen Stellen mit 1er. Das Ergebnis wird in \texttt{rD} gespeichert.
\item
\textbf{\texttt{cntlzw}}: \textit{Count Leading Zeros Word}
\item \dots{}
\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\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
--- /dev/null
+int sum(int len, int arr[])
+{
+ int i;
+ int sum = 0;
+ for (i = 0; i < len; i++) {
+ sum += arr[i];
+ }
+ return sum;
+}
projects / calu.git / commitdiff