assembler · Desktop-Simulator
Die Assembler-Desktop-Anwendung: Quelltexteditor, Prozessorschema mit Bussen und Registern und übereinanderliegende Bereiche für Speicher, Maschinencode und Mikrocode.

Überblick

Ein CPU-Simulator für den Desktop, der einen Befehlssatz mit 47 Befehlen assembliert und Mikrocodeschritt für Mikrocodeschritt ausführt. Der Datenpfad im Schaltbild leuchtet dabei mit.

Ein Student schreibt zehn Zeilen Assembler, drückt auf Step und sieht zu, wie ein Wert über den Bus in ein Register wandert.

  • Assembler-Quelltext im Editor schreiben oder öffnen
  • Starten, pausieren, im Einzelschritt ausführen oder zurücksetzen, im gewählten Tempo
  • Aktive Busse und Register auf dem Prozessor-Schaltbild aufleuchten sehen
Auf einen Blick
RolleAlleinentwickler, Neuaufbau eines Lehrsimulators in Schichten
AufbauVier Projekte, Abhängigkeitspfeil in eine Richtung, die Domäne hängt von nichts ab
Befehlssatz47 Mnemonics in vier Kodierungsklassen, vier Adressierungsarten
ZielplattformenWindows und Mac Catalyst, Englisch und Rumänisch
Tests83 Testmethoden über 80 Datenzeilen, in drei Testprojekten
GateStyleCop und .NET-Analyzer, Warnungen als Fehler
QuellcodeClosed Source

Architektur

Vier Schichten und eine Domäne, die morgen aus einer Konsole laufen könnte.

textAbhängigkeitsrichtung: von Maui über Presentation und UseCases zu Domain

src/
├── Assembler.Domain/        Pure CLR: ISA, assembler, microcode, simulator core
├── Assembler.UseCases/      Facades and fluent builders over the domain
├── Assembler.Presentation/  AppPresenter (MVP), AppStateMachine (FSM), view ports
└── Assembler.Maui/          .NET MAUI: one ViewModel per pane, drawn schematic, dialogs
  • Die Domäne nutzt kein UI-Framework und startet keine Timer. Verzögerungen kommen über eine injizierte Clock.
  • Jeder Effekt verlässt die Domäne als typisiertes Event über einen Channel.
  • Ich habe MVP statt reinem MVVM gewählt, damit ein Presenter die Koordination hält und nicht jeder Bereich.
  • Die einzigen Pakete sind MAUI und CommunityToolkit.Mvvm. Das Schaltbild ist von Hand gezeichnet.

Domänendesign

Ein Befehlssatz, in dem der Opcode berechnet und nicht nachgeschlagen wird.

  • 47 Mnemonics in vier Kodierungsklassen, vier Adressierungsarten, sechzehn Register.
  • Jeder Befehl läuft als Mikrocodeprogramm, das genau den Bus benennt, den er nutzt.
  • Die Domäne sagt „der S-Bus wurde aktiviert“, nie „hebe das hervor“. So kann sich die Zeichnung ändern, ohne den Simulator anzufassen.

Daten- und Kontrollfluss

Ein Druck auf Step, vom Knopf bis zum leuchtenden Bus.

  1. Der Presenter schickt einen Trigger an den Zustandsautomaten. Ein abgelehnter Übergang bewirkt nichts.
  2. Der Simulator holt, dekodiert und führt den Mikrocode eines Befehls aus.
  3. Jeder Schritt meldet, was er berührt hat: Bus, Register, Flags.
  4. Der Presenter verteilt jedes Event an die offenen Bereiche, und das Schaltbild zeichnet sich neu.

Teststrategie

Drei Testprojekte unterhalb der Oberfläche und keins oberhalb des Presenters.

  • Eine Golden-Encoding-Suite legt genau den Maschinencode fest, zu dem jeder Befehl assembliert wird.
  • Der Zustandsautomat ist vollständig getestet: 42 Zeilen, jeder erlaubte und abgelehnte Übergang.
  • Dank der injizierten Clock ist ein zwanzig Sekunden langer Lauf im Test in Mikrosekunden fertig.
  • StyleCop und .NET-Analyzer, Warnungen als Fehler. Ein undokumentierter Member lässt den Build fehlschlagen.

Was ich ändern würde

  • Das Schaltbild behält seine helle Palette, während alle anderen Bereiche dunkel sind. Es sollte das Theme übernehmen.
  • Oberhalb des Presenters ist nichts getestet. Ein automatisierter Smoke-Test ist der realistische nächste Schritt.
  • Der Zustandsautomat hat keine Entry- oder Exit-Aktionen: gut bei neun Zuständen, nicht bei dreißig.
  • Der Mikrocodekatalog ist fest eingebaut. Ihn aus einer Datei zu laden, würde Studierenden am meisten helfen.