diff options
Diffstat (limited to 'ue3/protokoll/protokoll.tex')
| -rw-r--r-- | ue3/protokoll/protokoll.tex | 144 |
1 files changed, 129 insertions, 15 deletions
diff --git a/ue3/protokoll/protokoll.tex b/ue3/protokoll/protokoll.tex index 8b413e7..dd53735 100644 --- a/ue3/protokoll/protokoll.tex +++ b/ue3/protokoll/protokoll.tex | |||
| @@ -38,44 +38,110 @@ Manuel Mausz, \matrnr 0728348\\ | |||
| 38 | 38 | ||
| 39 | Abbildung~\ref{fig:classdiagram1} zeigt das Klassendiagramm der Aufgabe. | 39 | Abbildung~\ref{fig:classdiagram1} zeigt das Klassendiagramm der Aufgabe. |
| 40 | 40 | ||
| 41 | TODO | 41 | Als Datentyp für Register und Hauptspeicher der CPU wurde ein allgemeines |
| 42 | Template implementiert, welche andere Datentypen oder Klasse umhüllen kann. | ||
| 43 | Zudem wurden die gängigsten Operatoren definiert, die man sich von einem | ||
| 44 | Datentyp erwarten kann. Gemäß der Aufgabenstellung wurde der Datentyp CDat als | ||
| 45 | umhüllter Integer-Wert definiert. | ||
| 46 | |||
| 47 | Der Hauptspeicher der CPU wurde als abgeleitetes Template \mbox{CVectorMem} des | ||
| 48 | Templates \mbox{std::vector<T, Allocator>} implementiert, damit dieses um die | ||
| 49 | Methode \mbox{initialize} und \mbox{dump} erweitert werden konnten. Erstere | ||
| 50 | dient zur Initialisierung des Hauptspeichers bzw. Füllung des Vectors, | ||
| 51 | zweiteres zur Debugausgabe. Der Datentyp CMem wurde via typedef als | ||
| 52 | \mbox{CVectorMem} mit dem Templateargument CDat definiert. Somit enthält der | ||
| 53 | Hauptspeicher nur Elemente des Typs CDat. | ||
| 54 | |||
| 55 | Die geforderten zwei Display-Klassen \mbox{CDisplayWDEZ} und | ||
| 56 | \mbox{CDisplayWHEX} wurden von der abstrakten Klasse CDisplay abgeleitet, welche | ||
| 57 | selbst als Template CDisplayT mit dem Templateargument CDat definiert ist. | ||
| 58 | |||
| 59 | Der Programmspeicher \mbox{CProgram} wurde vom Template | ||
| 60 | \mbox{std::vector<CInstruction *>} abgeleitet. Somit ist diese Klasse, ähnlich | ||
| 61 | wie CMem, selbst ein Vector. Zudem wurden weitere Methoden hinzugefügt. Die | ||
| 62 | Methode \mbox{compile} dient zum Kompilieren bzw. Umwandeln des | ||
| 63 | Syntax der Programmdatei in Instanzen der Klasse CInstruction, die später von | ||
| 64 | der CPU ausgeführt werden. Zur Umwandlung werden bei der Instantiierung von | ||
| 65 | \mbox{CProgram} sämtliche erlaubten Instruktionen (also Instanzen von | ||
| 66 | \mbox{CInstruction}) in ein \mbox{std::set} eingefügt. Im Zuge der Methode | ||
| 67 | \mbox{compile} wird durch Iterieren die jeweilige Instruktion gesucht und durch | ||
| 68 | Anwendung des Designpattern \textit{Factory method pattern} die Instruktion | ||
| 69 | dupliziert und in \mbox{CProgram} gespeichert. Labels werden zwecks Effizienz in | ||
| 70 | einer \mbox{std::map} festgehalten. | ||
| 71 | |||
| 72 | Die jeweiligen unterstützen Instruktionen wurden wie gefordert von der Klasse | ||
| 73 | \mbox{CInstruction} abgeleitet. \mbox{CInstruction} fordert die | ||
| 74 | Implementierung einer Methode \mbox{compile}, die während des parsens der | ||
| 75 | Programmdatei von \mbox{CProgram} aufgerufen werden, als auch eine Methode | ||
| 76 | \mbox{execute}, die im Zuge der Ausführung des Programms von CCPU | ||
| 77 | aufgerufen werden. | ||
| 78 | |||
| 79 | Die eigentliche CPU wird durch die Klasse \mbox{CCPU} implementiert. Diese | ||
| 80 | dient hauptsächlich als Container für die einzelnen, notwendigen Teile | ||
| 81 | (Hauptspeicher, Programmspeicher, Displays, ...) und besitzt daher entsprechend | ||
| 82 | viele get- und set-Funktionen. Die Methode \mbox{run} dient zur Ausführung des | ||
| 83 | Programms und ist eine Schleife, die über die Instruktionen iteriert und die | ||
| 84 | Methode \mbox{execute} aufruft. | ||
| 42 | 85 | ||
| 43 | %================================================================== | 86 | %================================================================== |
| 44 | \begin{figure}[htb] | 87 | \begin{center} |
| 45 | \begin{center} | 88 | \begin{figure}[htb] |
| 46 | \epsfxsize=0.9\textwidth\epsfbox{mycpu.png} | 89 | \epsfxsize=1.6\textwidth\epsfbox{mycpu.png} |
| 47 | \end{center} | 90 | \caption{Klassendiagramm 1} |
| 48 | \caption{Klassendiagramm 1} | 91 | \label{fig:classdiagram1} |
| 49 | \label{fig:classdiagram1} | 92 | \end{figure} |
| 50 | \end{figure} | 93 | \end{center} |
| 51 | %================================================================== | 94 | %================================================================== |
| 52 | 95 | ||
| 53 | \subsection{Verwaltung der Ressourcen} | 96 | \subsection{Verwaltung der Ressourcen} |
| 54 | 97 | ||
| 55 | TODO | 98 | Alle Objekte, die im Konstruktor alloziert werden, werden im Destruktor wieder |
| 99 | freigegeben. Die Objekte, die über die \textit{Factory method pattern} | ||
| 100 | alloziert werden, werden im Zuge des Destruktor des Vectors bzw. | ||
| 101 | von \mbox{CProgram} wieder freigegeben. | ||
| 56 | 102 | ||
| 57 | \subsection{Fehlerbehandlung} | 103 | \subsection{Fehlerbehandlung} |
| 58 | 104 | ||
| 59 | TODO | 105 | Es wurden keine eigenen Exceptions eingeführt. Statt dessen werden Exceptions |
| 106 | meist in Exceptions des Typs \mbox{std::runtime\_error} umgewandelt. Da die | ||
| 107 | Hierarchie nicht sehr tief ist, fängt lediglich \mbox{CPropram::compile} | ||
| 108 | Exceptions des Typs \mbox{std::runtime\_error}, um zusätzliche Information an | ||
| 109 | den ursprünglichen Aufrufer der Methode weiterzugeben. Dies geschieht ebenfalls | ||
| 110 | per Exception des Typs \mbox{std::runtime\_error}. | ||
| 60 | 111 | ||
| 61 | \subsection{Implementierung} | 112 | \subsection{Implementierung} |
| 62 | 113 | ||
| 63 | TODO | 114 | Siehe Punkt~\ref{Design} und Abbildung~\ref{fig:classdiagram1} sowie |
| 64 | 115 | Punkt~\ref{Listings}.\\ | |
| 116 | Es wurde viel mit Templates gearbeitet. | ||
| 65 | 117 | ||
| 66 | \section{Projektverlauf} | 118 | \section{Projektverlauf} |
| 67 | 119 | ||
| 68 | \subsection{Probleme und Fallstricke} | 120 | \subsection{Probleme und Fallstricke} |
| 69 | 121 | ||
| 70 | TODO | 122 | Abgesehen von den mittlerweile üblichen Schwierigkeiten die Angabe bzw. |
| 123 | die Gedanken dessen Verfassers verstehen zu wollen, arbeitete das erste Design | ||
| 124 | noch vermehrt mit Text. Unter anderem hatte die Methode | ||
| 125 | \mbox{CInstruction::execute} einen Parameter des Typs \mbox{std::string}, was | ||
| 126 | zum dazu führte, das die Instruktion bei jeder Aufführung (zum Beispiel durch | ||
| 127 | Jumps) erneut geparsed werden musste. | ||
| 71 | 128 | ||
| 72 | \subsection{Arbeitsaufwand} | 129 | \subsection{Arbeitsaufwand} |
| 73 | 130 | ||
| 74 | \begin{tabular}{ll} | 131 | \begin{tabular}{ll} |
| 75 | \toprule | 132 | \toprule |
| 76 | Entwicklungsschritt / Meilenstein & Arbeitsaufwand in Stunden\\ | 133 | Entwicklungsschritt / Meilenstein & Arbeitsaufwand\\ |
| 134 | \midrule | ||
| 135 | Erstes Design & 3 Stunden\\ | ||
| 136 | \hline | ||
| 137 | Implementierung & 3 Tage\\ | ||
| 138 | \hline | ||
| 139 | Anpassung des Designs und der Implementierung & 4 Stunden\\ | ||
| 140 | \hline | ||
| 141 | Dokumentation (Doxygen) und Überprüfung aller\\ | ||
| 142 | Anforderungen gemäß der Programmierrichtlinien & 4 Stunden\\ | ||
| 77 | \hline | 143 | \hline |
| 78 | TODO & TODO\\ | 144 | Erstellung des Protokolls & 3 Stunden\\ |
| 79 | \bottomrule | 145 | \bottomrule |
| 80 | \end{tabular} | 146 | \end{tabular} |
| 81 | 147 | ||
| @@ -88,5 +154,53 @@ TODO | |||
| 88 | \subsection{mycpu.cpp} | 154 | \subsection{mycpu.cpp} |
| 89 | \lstinputlisting{../mycpu/mycpu.cpp} | 155 | \lstinputlisting{../mycpu/mycpu.cpp} |
| 90 | 156 | ||
| 157 | \newpage | ||
| 158 | \subsection{cdat.h} | ||
| 159 | \lstinputlisting{../mycpu/cdat.h} | ||
| 160 | |||
| 161 | \newpage | ||
| 162 | \subsection{cmem.h} | ||
| 163 | \lstinputlisting{../mycpu/cmem.h} | ||
| 164 | |||
| 165 | \newpage | ||
| 166 | \subsection{cinstruction.h} | ||
| 167 | \lstinputlisting{../mycpu/cinstruction.h} | ||
| 168 | |||
| 169 | \newpage | ||
| 170 | \subsection{cinstruction.cpp} | ||
| 171 | \lstinputlisting{../mycpu/cinstruction.cpp} | ||
| 172 | |||
| 173 | \newpage | ||
| 174 | \subsection{instructions.h} | ||
| 175 | \lstinputlisting{../mycpu/instructions.h} | ||
| 176 | |||
| 177 | \newpage | ||
| 178 | \subsection{instructions.cpp} | ||
| 179 | \lstinputlisting{../mycpu/instructions.cpp} | ||
| 180 | |||
| 181 | \newpage | ||
| 182 | \subsection{cdisplay.h} | ||
| 183 | \lstinputlisting{../mycpu/cdisplay.h} | ||
| 184 | |||
| 185 | \newpage | ||
| 186 | \subsection{displays.h} | ||
| 187 | \lstinputlisting{../mycpu/displays.h} | ||
| 188 | |||
| 189 | \newpage | ||
| 190 | \subsection{cprogram.h} | ||
| 191 | \lstinputlisting{../mycpu/cprogram.h} | ||
| 192 | |||
| 193 | \newpage | ||
| 194 | \subsection{cprogram.cpp} | ||
| 195 | \lstinputlisting{../mycpu/cprogram.cpp} | ||
| 196 | |||
| 197 | \newpage | ||
| 198 | \subsection{ccpu.h} | ||
| 199 | \lstinputlisting{../mycpu/ccpu.h} | ||
| 200 | |||
| 201 | \newpage | ||
| 202 | \subsection{ccpu.cpp} | ||
| 203 | \lstinputlisting{../mycpu/ccpu.cpp} | ||
| 204 | |||
| 91 | \end{document} | 205 | \end{document} |
| 92 | 206 | ||
