Chili Palmer
a6f005d023
- Neue Hauptspecs: bytecode-kompilat, vm-ausfuehrung, vm-fehlerbehandlung, konsolen-basisbibliothek - Erweitert: sprach-frontend (Typisiertes HIR als Sema-Ausgabe), kompat-testkorpus (Laufzeitvergleich, Phase-2-Korpusabdeckung) - Change nach openspec/changes/archive/2026-09-02-phase-2-bytecode-vm verschoben; openspec validate --all: 9/9 Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
3.1 KiB
Purpose
Das Bytecode-Kompilat ist das serialisierbare Ergebnis der Übersetzung:
Der Codegenerator senkt das typisierte HIR in einen monomorphen
Opcode-Satz ab, der .tbc-Container hält es als stabiles, dokumentiertes
Format, und das Instant-Compile-Budget sichert den schnellen
Edit-Run-Zyklus.
ADDED Requirements
Requirement: Monomorpher Opcode-Satz
Der Codegenerator SHALL jedes HIR-Konstrukt in typisierte, monomorphe Opcodes übersetzen: Arithmetik, Vergleiche und Konvertierungen tragen den Operandentyp im Opcode (kein Tag-Dispatch über Werte zur Laufzeit); implizite Konvertierungen erscheinen als explizite Konvertierungs-Opcodes an den vom HIR bestimmten Stellen. Der Opcode-Satz SHALL in docs/tbvm-design.md vollständig dokumentiert sein.
Scenario: Gemischter Ausdruck wird monomorph
- WHEN
d# = i% + 1.5#übersetzt wird (INTEGER-Variable, DOUBLE-Ziel) - THEN enthält der Bytecode einen Konvertierungs-Opcode INTEGER→DOUBLE und eine DOUBLE-Addition, keinen generischen Additions-Opcode
Scenario: Namen sind zur Laufzeit aufgelöst
- WHEN eine Variable oder Prozedur im Bytecode referenziert wird
- THEN geschieht das über Slot- bzw. Tabellenindizes, nicht über Namens-Lookups
Requirement: .tbc-Containerformat
Das Kompilat SHALL als .tbc-Datei serialisierbar und wieder ladbar sein:
Magic TBC\0, Formatversion, Abschnittstabelle mit den Abschnitten
CONSTS (deduplizierter Konstantenpool), TYPES (TYPE-Layouts), PROCS
(modul-qualifizierte Prozedurtabelle mit Signatur, Locals-Anzahl,
Code-Offset), CODE, DATA (READ/RESTORE-Segment) und LINES
(Zeilentabelle). Laden und erneutes Serialisieren MUST verlustfrei sein;
eine unbekannte Formatversion MUST mit einer klaren Fehlermeldung
abgewiesen werden.
Scenario: Roundtrip
- WHEN ein kompiliertes Modul als
.tbcgeschrieben und wieder geladen wird - THEN ist das geladene Kompilat funktional identisch (gleiche Ausführung, gleiche Zeilenzuordnung)
Scenario: Unbekannte Version
- WHEN eine
.tbc-Datei mit höherer Formatversion geladen wird - THEN wird das Laden mit einer Meldung abgelehnt, die die Version nennt
Requirement: Zeilentabelle für Fehlerortung
Der Bytecode SHALL jede Anweisung ihrem Ursprung (Moduldatei, Zeile)
zuordnen, sodass Laufzeitfehlermeldungen, ERL, Breakpoints und
Einzelschritt die Quellzeile exakt benennen können.
Scenario: Fehler nennt Zeile
- WHEN in Zeile 42 eines Programms ein Laufzeitfehler ohne Handler auftritt
- THEN nennt die Fehlermeldung Zeile 42
Requirement: Instant-Compile-Budget
Die Übersetzung (Lexen bis Bytecode) SHALL ohne globale Analysepasses auskommen; Vorwärtsreferenzen werden über Fixups aufgelöst. Ein Benchmark MUST das Budget nachweisbar machen: ein Projekt von ~50.000 Zeilen kompiliert in unter 1 s, ein einzelnes Modul in unter 50 ms (Release-Build, Referenzrechner); die Messwerte werden in docs/tbvm-design.md festgehalten.
Scenario: Budget wird gemessen
- WHEN die Benchmarks in
benches/laufen - THEN wird die Kompilierzeit für das ~50k-Zeilen-Projekt und für ein Einzelmodul ausgewiesen und gegen das Budget verglichen