CPU Simulator
So, Achtung, Nerd-Alarm. Oder auch, neues aus der Reihe: Was studier ich hier eigentlich?
Wir haben hier an der London South Bank University tatsächlich mal eine Aufgabe bekommen, deren Ergebnis es meiner Meinung nach wert ist, veröffentlicht zu werden.
Der vollständige Bericht über die Aufgabe umfasst 10 Seiten. Das würde den Rahmen eines Blog-Posts ein wenig sprengen, weshalb ich hier nur einen kurzen Überblick gebe. Swing ist zwar nicht unbedingt erste Wahl bei der GUI-Entwicklung, aber man kommt damit bei Java relativ schnell zu brauchbaren Ergebnissen. Um den Simulator zu verwenden, sollte man vielleicht schon mal Assembler programmiert haben. Und um Nutzen von den Ausgaben zu haben, sollte man wenigstens eine grobe Idee von den Abläufen innerhalb einer CPU haben – sonst wird man denken: Oh, toll, Zahlen und Buchstaben in Tabellen…
However, Aufgabe eines Assignments im Modul “Advanced Computer Engineering” war es, einen “simplen” CPU-Simulator zu entwickeln. Heißt, ein Programm, welches die einzelnen Schritte simuliert, die ein Prozessor auf niedrigster Ebene ausführt. Natürlich mit vielen Einschränkungen – man entwickelt ja nicht mal eben so in zwei Tagen ne komplette CPU-Logik. Haupt Augenmerk sollte auf dem Fetch-Decode-Execute-Zyklus liegen, mit dem der Prozessor die einzelnen Instruktionen ausführt. Das ist insofern besonders interessant, weil es quasi “umgekehrtes Assembler” ist, was wir dort implementieren sollten.
In der Aufgabenstellung war vorgegeben, dass es ein 8-Bit-Prozessor sein soll. “8-Bit” meint in diesem Fall, dass jede Instruktion, die der Prozessor ausführen kann, 8 Bit lang ist. In diesen 8 Bit müssen Opcode (Auszuführender Befehl), Adressierungs-Mode-Indicator (Direkte oder Indirekte Adressierung?) und Operand untergebracht werden. Das resultierte in diesem Fall in folgender Zerlegung:
Bei 23 wären 8 Befehle adressierbar. Da ich hier momentan auch noch andere Sachen zu tun hab und es für die Aufgabe mehr als genug war, habe ich bisher nur 4 Befehle implementiert:
LDA – Lade Accu
ADD – Addition ohne carry o.ä.
STO – Speichere Accu in Daten-Speicher
GOT – Goto Code-Speicher-Stelle
Jeweils mit der Möglichkeit der direkten oder indirekten Adressierung. LDA 0 lädt den Accu mit dem Wert 0, LDA @0 lädt den Accu mit dem Wert, der an Stelle 0 im Daten-Speicher liegt. ADD, STO und GOT funktionieren sinngemäß.
1 Bit zeigt den Adressierungsmodus an und 4 Bit stehen als Operand zur Verfügung. Als Operand sind also nur 4-Bit-Werte zulässig, im Command durch eine Ziffer im Hexedezimal System repräsentiert. Das resultiert in einem Wertebereich für den Operanden von 0-1510 bzw. 0×0 – 0xF16. Da sowohl Code- als auch Daten-Speicher je über 16 Speicheradressen verfügen, konnte so relativ einfach verhindert werden, dass Speicherbereiche außerhalb des Bereichs 0-1510 adressiert werden.
Die umgesetzte Trennung von Code- und Daten-Speicher ist natürlich auch nur teilweise realistisch, hat für die Umsetzung dieser Aufgabe aber viele Unannehmlichkeiten erspart.
Startet man nun meinen Simulator, kann man die Command-Spalte des Code-Speichers editieren. Die dort eingegebenen Commands (entsprechend der Tabelle oben) werden per “Translate” je in eine 8-Bit-Instruction übersetzt. Hat die Übersetzung funktioniert (ein paar Syntax- und Logik-Checks habe ich eingebaut), kann man per “Step”, Schritt für Schritt durch sein eigenes kleines Assembler Programm laufen. Ausgeführt werden dabei dann aber nicht die “Assembler-Commands”, sondern die 8-Bit-Instructions. Sie werden eine nach der anderen geladen, decodiert und ausgeführt. Diesen Ablauf kann man jeweils über die Program-Register unten im Fenster verfolgen, wo jeweils die als nächstes anstehende Instruktion in decodierter Form angezeigt wird.
“Load Example” lädt – oh Wunder – ein Beispielprogramm, welches jeden implementierten Befehl min. 1x verwendet.
Die Jar-Datei des Simulators kann man bei Interesse hier herunterladen. Manchmal braucht sie zwei Doppel-Klicks, fragt mich nicht warum. Aber ansonsten sollte sie eigentlich bei jedem starten, der das Java Runtime Environment installiert hat, was ja heutzutage fast jeder PC braucht.
Bericht und Quellcode werde ich vorerst noch nicht veröffentlichen. Es gibt ein paar Studenten hier, die einem die Lösungen beim Tippen von der Tastatur weg-kopieren würden, wenn sie könnten.


