4 files changed, 61 insertions, 37 deletions

diff --git a/ue4/protokoll.pdf b/ue4/protokoll.pdf
index 06311b9..b3dc60d 100644
--- a/ue4/protokoll.pdf
+++ b/ue4/protokoll.pdf
diff --git a/ue4/protokoll/mycpu.png b/ue4/protokoll/mycpu.png
new file mode 100644
index 0000000..c394605
--- /dev/null
+++ b/ue4/protokoll/mycpu.png
diff --git a/ue4/protokoll/mycpu.vpp b/ue4/protokoll/mycpu.vpp
new file mode 100644
index 0000000..14730dc
--- /dev/null
+++ b/ue4/protokoll/mycpu.vpp
diff --git a/ue4/protokoll/protokoll.tex b/ue4/protokoll/protokoll.tex
index 87a556a..53f57df 100644
--- a/ue4/protokoll/protokoll.tex
+++ b/ue4/protokoll/protokoll.tex
@@ -1,4 +1,5 @@
 \documentclass[12pt,a4paper,titlepage,oneside]{article}
+
 \usepackage[utf8]{inputenc}
 \usepackage{oop_prot}
 \usepackage{url}
@@ -37,31 +38,44 @@ Manuel Mausz, \matrnr 0728348\\
 
 Abbildung~\ref{fig:classdiagram1} zeigt das Klassendiagramm der Aufgabe.
 
-Wie gefordert, wurden die zwei zusätzliche Datentypen, \mbox{CDatSet} und \mbox{CDatN},  implementiert und der Programmcode generisch gestaltet. 
-
-Dabei wurde \mbox{CDatSet} vom existierenden Typ \mbox{CDat} und boost::operators<\mbox{CDatSet}> mittels Mehrfachvererbung abgeleitet.
-So war es möglich die Implementierung, mittels Codewiederverwendung, auf das Überschreiben eines Kopierkonstruktors und des Operators \mbox{operator>>()} zu beschränken.  
-
-Da der Typ \mbox{CDatN} Werte variabler Bitlänge repräsentiert, war es notwendig diesen vollständig neu zu implementieren. Es wurde von boost::operators<\mbox{CDatN}> abgeleitet und dabei eine zusätzliche 
-Methode  \mbox{align()} definiert, die sicherstellt, dass der transportierte Wert immer auf die geforderte Bitanzahl konvertiert wird.
-Weiters wurde ein Kopierkonstruktor definiert, der einen Integerwert und einen vorzeichenlosen Integerwert als Argument erwartet.
-Letzterer ist mit dem Defaultwert 31 deklariert und repräsentiert die Bitanzahl, auf die ersterer konvertiert wird. Damit ist es möglich alle vorhandenen Datentypen einheitlich zu verarbeiten.
-Der Defaultkonstruktor wurde wie gewünscht deaktiviert.
-
-Um nun die Wahl des Datentyps zu ermöglichen, wurde die Synopsis des Programms mit \mbox{``-f''} erweitert.
-Der Parameter dieser Option muss \mbox{``s''} oder ein Wert zwischen ``2'' und ``32'' sein. 
-Im Hauptprogramm wird nun anhand dieses Parameters der zuständige Datentyp instanziert und die Templatemethode
-\mbox{cpu\_run()} aufgerufen, welche die Initialisierung und Abarbeitung des Programms anstößt.
-
-Damit das Programm mit den verschiedenen Datentypen umgehen kann, wurden \mbox{CCPU}, \mbox{CMem}, \mbox{CProgram}, \mbox{CInstuction} und die abgeleiteten  \mbox{Instructions}
-zu Templates umgewandelt, die als Typparameter den, im Hauptprogramm, instanzierten Datentyp erhalten.
+Wie gefordert wurden die zusätzliche Datentypen \mbox{CDatSet} und
+\mbox{CDatN} implementiert und der Programmcode generisch gestaltet.
+
+Dabei wurde \mbox{CDatSet} vom existierenden Typ \mbox{CDat} und
+\mbox{boost::operators<CDatSet>} mittels Mehrfachvererbung abgeleitet. So war es
+möglich die Implementierung, mittels Codewiederverwendung, auf das Überschreiben
+eines Kopierkonstruktors und des Operators \mbox{operator>>()} zu beschränken.
+
+Da der Typ \mbox{CDatN} Werte variabler Bitlänge repräsentiert, war es notwendig
+diesen vollständig neu zu implementieren. Es wurde von
+\mbox{boost::operators<CDatN>} abgeleitet und dabei in jeder
+Methode sicherstellt, dass der transportierte Wert immer auf die geforderte
+Bitanzahl beschränkt wird. Weiters wurde ein Kopierkonstruktor definiert, der
+einen Integerwert und einen vorzeichenlosen Integerwert als Argument erwartet.
+Letzterer ist mit dem Defaultwert 31 deklariert und repräsentiert die Bitanzahl,
+auf die Ersterer beschränkt wird. Damit ist es möglich alle vorhandenen
+Datentypen einheitlich zu verarbeiten. Der Defaultkonstruktor wurde wie
+gewünscht deaktiviert.
+
+Um nun die Wahl des Datentyps zu ermöglichen, wurde die Synopsis des Programms
+mit \mbox{``-f''} erweitert. Der Parameter dieser Option muss \mbox{``s''} oder
+ein Wert zwischen ``2'' und ``32'' sein. Im Hauptprogramm wird anhand dieses
+Parameters der zuständige Datentyp instanziert und die Templatemethode
+\mbox{cpu\_run()} aufgerufen, welche die Initialisierung und Abarbeitung des
+Programms anstößt.
+
+Damit das Programm mit den verschiedenen Datentypen umgehen kann, wurden
+\mbox{CCPU}, \mbox{CMem}, \mbox{CProgram}, \mbox{CInstuction} und die
+abgeleiteten \mbox{Instructions} zu Templates umgewandelt, die als
+Template-Parameter den Typ des im Hauptprogramm instanzierten Datentyps,
+erwarten.
 
 \newpage
 
 %==================================================================
 \begin{center}
   \begin{figure}[htb]
-    \epsfxsize=1.6\textwidth\epsfbox{mycpu.png}
+    \epsfxsize=1.1\textwidth\epsfbox{mycpu.png}
     \caption{Klassendiagramm 1}
     \label{fig:classdiagram1}
   \end{figure}
@@ -71,43 +85,53 @@ zu Templates umgewandelt, die als Typparameter den, im Hauptprogramm, instanzier
 \newpage
 \subsection{Verwaltung der Ressourcen}
 
-Die Register von \mbox{CCPU} werden nun, anstatt in einem Array, in einem Vector verwaltet. 
-Dieser wird mit der Anzahl der Register und dem, im Hauptprogramm, instanzierten Datentyp initialisiert.
-Dadurch ist das Löschen der Register im Destruktor nicht mehr notwendig.
+Die Register von \mbox{CCPU} werden nun, anstatt in einem Array, in einem Vector
+verwaltet. Dieser wird mit der Anzahl der Register und dem, im Hauptprogramm,
+instanzierten Datentyp initialisiert. Dadurch ist das eigenhändige Löschen der
+Register im Destruktor nicht mehr notwendig, da dies der Destruktor des Vectors
+erledigt.
 
-Siehe auch Punkt~\ref{Probleme und Fallstricke}.\\ 
+Siehe auch Punkt~\ref{Probleme und Fallstricke}.\\
 
 \subsection{Fehlerbehandlung}
 
-Es wurden mehrere Exceptions, als Subklassen der jeweiligen Templateklassen, von Typ \mbox{std::invalid\_argument} abgeleitet.
-Diese sind \mbox{CCPUError}, \mbox{CInstructionError}, \mbox{CMemError} und \mbox{CProgramError}.
+Es wurden mehrere Exceptions von der Klasse \mbox{std::invalid\_argument}
+abgeleitet. Diese sind \mbox{CCPUError}, \mbox{CInstructionError},
+\mbox{CMemError} und \mbox{CProgramError} und werden von ihren
+zugehörigen Klassen entsprechend geworfen.
 
-Wird zB.: eine Exception von Typ \mbox{CInstructinError} geworfen, so wird sie in \mbox{CCPU} zu \mbox{CCPUError} umgewandelt und an das Hauptprogramm weitergereicht, 
-wo wider eine Umwandlung in \mbox{runtime\_error()} stattfindet. Das Fangen einer \mbox{runtime\_error()} Exeption bewirkt eine fehlerbeschreibende Ausgabe auf \mbox{std::cerr}
-und den Programmabbruch mit Exitstatus 1. 
+Wird zB.: eine Exception von Typ \mbox{CInstructinError} geworfen, so wird sie
+in \mbox{CCPU} zu \mbox{CCPUError} umgewandelt und an das Hauptprogramm
+weitergereicht, in dem wiederum eine Umwandlung in \mbox{runtime\_error()}
+stattfindet. Das Fangen einer \mbox{runtime\_error()} Exeption bewirkt eine
+fehlerbeschreibende Ausgabe auf \mbox{std::cerr} und den Programmabbruch mit
+Exitstatus 1.
 
 \subsection{Implementierung}
 
 Siehe Punkt~\ref{Design} und Abbildung~\ref{fig:classdiagram1} sowie
 Punkt~\ref{Listings}.\\
 
-
-
 \section{Projektverlauf}
 
 \subsection{Probleme und Fallstricke}\label{Probleme und Fallstricke}
 
 \mbox{CDatN}:
 
-Mit der, in der Angabe vorgeschlagenen Methode zur Begrenzung der Bitanzahl,  ist es nur möglich positive Zahlen zu verarbeiten.
-Somit entspricht -1 dem Maximum der, mit der Bitanzahl, darstellbaren positiven Zahl usw..
+Mit der in der Angabe vorgeschlagenen Methode zur Begrenzung der Bitanzahl, ist
+es nur möglich positive Zahlen zu verarbeiten. Somit entspricht -1 dem Maximum
+der, mit der Bitanzahl, darstellbaren positiven Zahl usw..
 
-Ein weiteres Problem besteht darin, wenn die Anzahl der Instruktionen in CProgram, den maximal darstellbaren Wert übersteigt.
-In diesen Fall ist das Programmverhalten undefiniert.
+Ein weiteres Problem besteht darin, wenn Register nicht mehr gelesen werden
+können, weil der Index des Registers ausserhalb des Bereichs des Datentyps
+liegt. In diesen Fall ist das Programmverhalten undefiniert.
 
-Auf Grund der Forderung, den Defaultkonstruktor von \mbox{CDatN} zu deaktivieren, wurden einige Probleme initiiert.
-Es war nicht weiter möglich, die Register von \mbox{CCPU} in einem Array zu organisieren, da zur Deklaration ein Defaultkonstruktor notwendig ist. 
-Weiters musste eine Alternative zum, nicht mehr anwendbaren \mbox{boost::lexical\_cast} in \mbox{CMem} implementiert werden.
+Auf Grund der Forderung, den Defaultkonstruktor von \mbox{CDatN} zu
+deaktivieren, traten einige Probleme auf. So war es beispielsweise nicht weiter
+möglich, die Register von \mbox{CCPU} in einem Array zu organisieren, da zur
+Deklaration ein Defaultkonstruktor notwendig ist. Weiters musste eine
+Alternative zum nicht mehr anwendbaren \mbox{boost::lexical\_cast} in
+\mbox{CMem} implementiert werden.
 
 \subsection{Arbeitsaufwand}