Skip to content

Latest commit

 

History

History
218 lines (215 loc) · 9.14 KB

notes.org

File metadata and controls

218 lines (215 loc) · 9.14 KB
Raw

Notes

Tests mit Abgaben

Tetris (Felix Schoeller)

  • Absturz bei manchen Tetrominos wenn diese gedreht und an den rechten Bildschirmrand bewegt werden
  • Absturz auch in offiziellem Emulator (bei VM stdlib) -> kein Bug
  • Wird wahrscheinlich nicht mehr crashen, wenn alle stdlib Funktionen nativ sind

Minesweeper (Patrick Müller)

  • Absturz nach zu vielen Moves
  • Absturz auch in offiziellem Emulator -> kein Bug
  • Fehler war Memory leak, ist im offiziellen Emulator nicht so schnell aufgefallen, da dieser langsamer ist

Doom (Jona Leon Heywinkel)

  • Absturz wenn man ein bisschen nach Rechts geht, dann nach vorne (in den Dämon)
  • Absturz auch in offiziellem Emulator -> kein Bug

Raycaster (Julius Armbrüster)

  • läuft ohne Probleme
  • Performance wie in offiziellem Emulator, aber mit weniger jittering
  • Performance ist sehr abhängig von nativer Screen Implementierung

TODOs

CLI [2/2]

  • [X] Test Script runner [3/3]
    • [X] Korrekte ausführung der VM durch tst Skript [15/15]
      • [X] 07/MemoryAccess/StaticTest/StaticTestVME.tst
      • [X] 07/MemoryAccess/PointerTest/PointerTestVME.tst
      • [X] 07/MemoryAccess/BasicTest/BasicTestVME.tst
      • [X] 07/StackArithmetic/SimpleAdd/SimpleAddVME.tst
      • [X] 07/StackArithmetic/StackTest/StackTestVME.tst
      • [X] 08/FunctionCalls/StaticsTest/StaticsTestVME.tst
      • [X] 08/FunctionCalls/SimpleFunction/SimpleFunctionVME.tst
      • [X] 08/FunctionCalls/FibonacciElement/FibonacciElementVME.tst
      • [X] 08/FunctionCalls/NestedCall/NestedCallVME.tst
      • [X] 08/ProgramFlow/FibonacciSeries/FibonacciSeriesVME.tst
      • [X] 08/ProgramFlow/BasicLoop/BasicLoopVME.tst
      • [X] 12/ArrayTest/ArrayTest.tst
      • [X] 12/MemoryTest/MemoryTest.tst
      • [X] 12/MemoryTest/MemoryDiag/MemoryDiag.tst
      • [X] 12/MathTest/MathTest.tst
    • [X] Ausgabe mit cmp Datei vergleichen und ggfs Fehler anzeigen
    • [X] Output Datei neben cmp Datei speichern
  • [X] interface
    • [X] Skripte aus Ordner laden (cli argument)
    • [X] Tests ausführen wenn vorhanden (Struktur wie in projects Ordner)
    • [X] mit flag Desktop Modus starten
    • [X] steps per tick als cli argument

CPU Emulator [1/2]

  • [X] CPU Emulator implementieren
  • [ ] Test scripts als integration oder unit tests auführen

VM Emulator [9/12]

  • [X] alle commands implementieren
  • [X] command parsing
  • [X] funktionen erkennen die aufgerufen aber nicht deklariert werden
  • [X] native stdlib implementieren [8/8]
    • [X] Math
    • [X] String
    • [X] Array
    • [X] Output
    • [X] Screen
    • [X] Keyboard
    • [X] Memory
    • [X] Sys
  • [X] unbekannte funktionen in stdlib suchen und adden falls nötig
  • [X] Start der Ausführung bei Sys.init falls vorhanden
  • [X] Debug Infos für Funktionen
  • [X] Erfolgreiche Ausführung verschiedener Projekt 9 Abgaben
  • [X] Ordentliches error handling
    • [X] kein unwrap/expect
    • [X] keine [] Zugriffe in Listen (außer absolut sicher, wie z.B. in stdlib)
  • [ ] Debug Infos für lokale Label
  • [ ] checken ob Funktionsname zu Klassennamen passt
  • [ ] bei unknown token ParseError dateinamen anzeigen (oft nicht-vm datei)

VM Frontend [14/22]

  • [X] vm step aus frontend aufrufen
  • [X] display speicher in canvas rendern
  • [X] keyboard interaktion in vm speicher schreiben
  • [X] Geschwindigkeitsregulation
  • [X] Step Button
  • [X] Run Button
  • [X] Stop Button
  • [X] Revert Button
  • [X] Laden von User code
  • [X] Anzeige des Bytecodes
  • [X] Anzeige des Stacks
  • [X] Anzeige der Locals
  • [X] Anzeige der Arguments
  • [X] Anzeige des Call stacks
  • [ ] Anzeige der Statics
  • [ ] Anzeige des globalen RAMS
  • [ ] Anzeige von This
  • [ ] Anzeige von That
  • [ ] Anzeige von Temp
  • [ ] Anzeige des globalen Stacks
  • [ ] Numberformat switcher
  • [ ] Anzeige des Keyboard Inputs

BUGS/Fragen [2/3]

  • [X] Screen in VM zu groß bei 1080p -> scrolling
  • [ ] bytecode view sollte nur body scrollen, nicth den <file>: <function> header
  • [ ] Sollte die Anzeige des Stacks von unten nach oben verlaufen?
  • [X] VM fehler crasht UI

sonstiges [1/3]

  • [ ] Benchmark: da0ce4500f653afe7892395c63414eb1d05ff730 vs Nachfolger
  • [ ] Benchmark: 3fcc146df140f95a7be8290d897cc46b4dbccc59 vs Nachfolger
  • [X] Dependency section in Readme (auch für Desktop)

BA Inhaltsverzeichnis

Einleitung

  • Was ist Nand to Tetris
  • Warum macht es Sinn, die Nand to Tetris tools (im Browser) neu zu schreiben
    • UI auf großen Bildschirmen
    • Performance
    • kein Drang mehr die Tools zu installieren (zumindest nicht um VM Spiele zu spielen)
  • Hackenstein screenshot um komplexität zu zeigen

Generelles und Technologien

  • Was ist Wasm und wie unterscheidet es sich von JS
  • Was ist Rust
  • Welche Vorteile hat eine Implementierung in Rust gegenüber JS
    • Performance
    • Robuster durch starke statische Typisierung
  • Welche Vorteile hat Rust gegenüber anderen Sprachen die zu Wasm compilen können
    • kleine runtime & kein GC
    • sehr schnell
  • Was ist React und welche Vorteile bietet es gegenüber rohem JS

Abgrenzung zu Fremdleistungen

  • VM/CPU & TST Design aus Nand to Tetris
    • Spezifikationen aus “The Elements of Computing Systems”
  • Dependencies
    • Rust
      • lazy_static (hack um rust weniger nervig zu machen)
      • regex
      • wasm-bindgen (rust code für JS zugänglich machen)
      • web-sys (js stdlib in Rust nutzen)
      • console_error_panic_hook (rust panics zu JS exeptions)
      • sdl2 (native UI (eigentlich nur zum Testen))
      • clap (CLI parsing)
    • wasm-pack (rust -> wasm Kompilierung einfacher machen)
    • react & npm (UI)
  • Implementierung komplett eigen
    • Ansatz auch an einigen Stellen sehr anders als die offiziellen Tools (z.B. native stdlib, parsing, UI)
  • Related Work

Implementierung

  • Wie war mein generelles Vorgehen
    • zuerst VM basics test driven auf dem Desktop (ohne wasm) implementieren
      • dafür zuerst bytecode parser -> Benutzung in VM tests
      • native Rust stdlib erst als alle basics funktioniert haben (vorher offizielle VM Implementierung)
    • testing durch unit tests
    • testing mittels tst scripts aus dem Kurs (erst als rust unit tests, später auch via tst executor)
    • dann frontend unabhängig entwickeln, mit dünnem compatibility layer (lib.rs)
    • Verhalten immer wie im offiziellen Emulator
      • Beispiel keyboard handling: bug für bug compatibility
  • Architektur
    • verschiedene Programme für CPU, VM
    • Emulatoren komplett unabhängig von Frontend
      • erlaubt verschiedene Frontends (SDL)
      • oder auch headless mode, z.B. für die tst Scripts
      • rendering und keyboard handling aber in rust für performance und DRY
  • Wie funktionieren VMs und Bytecode
    • simples beispiel schrittweise erklären: schleife die [1, 3] addiert
  • VM Entwicklung in Rust
    • Wie habe ich die VMs in Rust implementiert
      • design entscheidung: enum vs union
      • stepweise ausführung mit pattern matching über enum
    • Wie habe ich die Parser in Rust implementiert
      • Lexer & Parser
      • Peekable
    • Beispiel für Rust Architektur anhand von tst file parser/executor
      • traits als Alternative für Vererbung
      • wenig code Duplikation
      • Kombination aus Parser und Executor muss zusammen passen (compile time check)
    • Rust compile time flags
      • verschiedene tracing modes
      • Desktop mode mit optionalen dependencies
    • Implementierung der Stdlib
      • step-weise Ausführung -> komplikationen bei stdlib Implementierung
      • Funktionen müssen pausierbar sein (ohne aber den Thread zu blockieren)
      • Rust Funktionen müssen VM Funktionen rufen können
      • VM Funktionen müssen Rust Funktionen rufen können
      • Beispiel des Ablaufs anhand einer simplen Funktion wie Sys.wait
      • Beispiel des Ablaufs anhand einer komplexen Funktion wie Output.printString oder Keyboard.readLine
      • Lösung: state machine ähnlich zu async await

Ergebnisse

  • Show case: Web UI
    • adaptiv für verschiedene screen größen
    • Fullscreen canvas
    • bytecode view und memory watches
    • rendering in rust
  • Hosting auf github pages
  • Performance Vergleich mit offiziellem Emulator
    • Ergebnisse als Graph (oft laufen lassen, verschiedene Rechner)
    • Warum ziehe ich Schluss aus Daten

Future work

  • Hardware simulator
  • mehr UI

Fazit

  • War das Projekt erfolgreich
    • wurden alle Ziele umgesetzt
      • ja: VM und CPU Emulator komplett benutzbar + tst scripts
    • welche Vorteile hat meine Implementierung gegenüber dem offiziellem Emulator
      • deutlich bessere Performance
      • bessere UI
      • vom Browser aus benutzbar
      • simples und einheitliches CLI für Korrektoren
      • besonders nützlich für die Implementierung und Korrektur von Projekt 9 wegen besserer Performance und größerem Screen
  • War Rust eine gute Wahl für dieses Projekt
    • hat es die erwarteten Vorteile gegenüber JS erbracht
      • Performance und Stabilität war gut
      • statische starke Typisierung ist hilfreich um stabilen Code zu schreiben
      • allerings auch oft unflexibel
      • refactoring oft umständlich wegen lifetimes
      • alles in allem war Rust aber eine gute Wahl
    • hat es Vorteile gegenüber anderen Sprachen die zu Wasm compilen erbracht
      • gutes WASM ökosystem mit vielen libraries

Anhang

  • Benutzerdokumentation
    • WebUI
    • Compilation
    • Benutzung in Skripten für Korrektoren