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>
66 lines
3.1 KiB
Markdown
66 lines
3.1 KiB
Markdown
# bytecode-kompilat Specification
|
|
|
|
## 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.
|
|
|
|
## 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 `.tbc` geschrieben 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
|