From 1ce371b96becff12e4db357af4b864ef4c45cd39 Mon Sep 17 00:00:00 2001 From: Chili Palmer Date: Tue, 1 Sep 2026 16:45:59 +0200 Subject: [PATCH] Leitbild und Performance-Anforderungen verankern - README: Leitbild Re-Imagination (Stufe 1 originalgetreu, Stufe 2 additive Anreicherung fuer CLI-/TUI-Tool-Entwicklung) - PLAN: Leitplanken (Online-Doku als Primaerquelle, Performance als Anforderung: Instant-Compile, Projekt-Build in Sekunden, Executable ohne Toolchain), Stufe-2-Ideenspeicher, Benchmark-Aufgaben in Phase 2 - tbvm-design: Performance-Abschnitt (Single-Pass, inkrementell, typisierte Opcodes, Slot-Aufloesung zur Compilezeit, Messlatten) Co-Authored-By: Claude Fable 5 --- PLAN.md | 60 ++++++++++++++++++++++++++++++++++++++++++--- README.md | 19 +++++++++++++- docs/tbvm-design.md | 33 +++++++++++++++++++++++++ 3 files changed, 108 insertions(+), 4 deletions(-) diff --git a/PLAN.md b/PLAN.md index 08dd6a4..4a9ba6c 100644 --- a/PLAN.md +++ b/PLAN.md @@ -10,11 +10,36 @@ Konvention: `[ ]` offen · `[x]` erledigt · `[~]` in Arbeit ## Leitplanken -- **Referenzverhalten schlägt Eleganz.** Bei Zweifeln zählt das beobachtbare - Verhalten des Vorbilds (inkl. Fehlercodes, Rundung, Formatierung), nicht - das, was „richtiger" wäre. Abweichungen werden dokumentiert. +- **Re-Imagination, nicht Emulation** (2026-09-01): Ziel ist ein BASIC zum + Bauen von Terminal-Tools (CLI und TUI). Stufe 1 ist die getreue + Nachbildung von UI/UX, Sprachstandard und Standardbibliothek des Vorbilds + — rekonstruiert aus vorhandener Online-Dokumentation (Manuals auf + archive.org, Wiki-Referenzen, zeitgenössische Artikel). Stufe 2 (nach + Phase 6) reichert die Sprache bewusst um Elemente außerhalb des Vorbilds + an; Erweiterungen sind additiv und brechen den Kernstandard nicht. +- **Referenzverhalten schlägt Eleganz — innerhalb von Stufe 1.** Bei Zweifeln + zählt das dokumentierte Verhalten des Vorbilds (inkl. Fehlercodes, Rundung, + Formatierung), nicht das, was „richtiger" wäre. Wo das Vorbild aber mit der + heutigen Plattform kollidiert (Codepages, DOS-Hardware, Segmente), gewinnt + die Plattform; solche Abweichungen werden in der Sprachreferenz dokumentiert. - **Markenrecht:** Der Name des Vorbilds wird in Code, Doku und Artefakten nicht verwendet. Wir sprechen vom „Vorbild" bzw. „dem Dialekt". +- **Performance ist Anforderung, nicht Politur** (2026-09-01): + - **Instant-Compile:** Der Compiler übersetzt so schnell, dass der Benutzer + nie auf einen Build wartet — Start aus der IDE fühlt sich wie beim + Vorbild an (Run drücken, Programm läuft). Budget: ein komplettes Projekt + kompiliert **in Sekunden** und liefert ein ausführbares Ergebnis; + einzelne Module im Millisekundenbereich. + - Architektur-Konsequenzen: Single-Pass-Design (Lexer/Parser/Codegen ohne + teure globale Analysen), modulweise inkrementelle Übersetzung (nur + Geändertes neu), keine Optimierungspasses, die den Turnaround kosten — + Schnelligkeit der VM kommt aus dem VM-Design, nicht aus einem Optimizer. + - **Schnelle Ausführung:** Die TBVM führt generierten Code zügig aus + (Details in docs/tbvm-design.md, Abschnitt „Performance"); Messlatte via + Benchmarks ab Phase 2. + - `tbdosc build --exe` erzeugt Executables **ohne** Compiler-/Linker- + Toolchain beim Anwender (vorkompilierter Runner + angehängtes `.tbc`) — + damit bleibt auch der Weg zum verteilbaren Binary im Sekundenbereich. - **Jede Phase endet mit lauffähigen Tests** gegen eine wachsende Kompatibilitäts-Testsuite (Verzeichnis `tests/compat`, geplant). @@ -23,6 +48,12 @@ Konvention: `[ ]` offen · `[x]` erledigt · `[~]` in Arbeit ## Phase 0 — Exploration und Grundsatzentscheidungen ### 0.1 Sprach- und Bibliotheksreferenz rekonstruieren + +Primärquelle ist vorhandene Online-Dokumentation (archive.org-Manuals, +Wiki-Referenzen zur QB/PDS-Familie, zeitgenössische Artikel, Screenshots). +Emulator-Sessions nur noch als Rückfallebene für Detailfragen, die die +Dokumentation nicht beantwortet. + - [~] Sprachreferenz zusammentragen: Anweisungen, Funktionen, Operatoren, Typsystem (INTEGER, LONG, SINGLE, DOUBLE, STRING, CURRENCY, feste Strings, `TYPE…END TYPE`), Typ-Suffixe (`% & ! # $ @`), @@ -37,6 +68,9 @@ Konvention: `[ ]` offen · `[x]` erledigt · `[~]` in Arbeit → [docs/dateiformate.md](docs/dateiformate.md) - [x] Laufzeitfehler-Katalog (Codes + Meldungstexte) erfasst und als `tb_runtime::errors` implementiert (inkl. Tests) +- [~] IDE-UX-Referenz: Menüstruktur, Fensterverwaltung, Farbschema, + Tastenbelegung, Editor-Verhalten des Vorbilds + → [docs/ide-referenz.md](docs/ide-referenz.md) - [~] Testkorpus aufbauen: kleine Referenzprogramme, deren erwartete Ausgabe dokumentiert ist → erste Programme in `tests/compat/`, Harness folgt mit Phase 2 (`tbdosc run` + Ausgabevergleich) @@ -113,6 +147,9 @@ in der Sprachreferenz unter „Abweichungen" dokumentiert. - [ ] Fehlerbehandlung: `ON ERROR GOTO/RESUME`, `ERR`/`ERL`, Fehlerkaskaden - [ ] Unterbrechbarkeit: Tick-Grenzen, Breakpoints, Einzelschritt, Variableninspektion (Grundlage für IDE-Debugger) +- [ ] Benchmarks in `benches/`: Compile-Budget messen (Projekt ≈50k Zeilen + < 1 s, einzelnes Modul < 50 ms) und VM-Durchsatz (Schleifen/Strings); + Ergebnisse in docs/tbvm-design.md festhalten - [ ] Meilenstein: Konsolen-Testkorpus läuft mit korrekter Ausgabe (`tbdosc run`) ## Phase 3 — Laufzeitbibliothek (`tb-runtime`) und Bildschirm (`tb-ui::screen`) @@ -166,6 +203,23 @@ in der Sprachreferenz unter „Abweichungen" dokumentiert. --- +## Stufe 2 — Anreicherung (nach Phase 6, Ideenspeicher) + +Bewusste Erweiterungen jenseits des Vorbilds — additiv, der Kernstandard +bleibt gültig. Noch nichts davon ist beschlossen; Sammlung wächst: + +- Sprachkomfort: `OPTION EXPLICIT`, Zeilenfortsetzung, `BYVAL` überall, + längere Bezeichner, `&&`-Literale? (jeweils opt-in) +- Terminal von heute: Bildschirmgrößen jenseits 80×25, 256/24-Bit-Farben, + Scrollback, Resize-Ereignisse als Forms-Ereignis +- Neue Steuerelemente (Tabelle/Grid, Baum, Statusleiste) im Stil der + Forms-Engine +- Standardbibliothek: Prozessaufrufe mit Pipes, Umgebungs-/Argument-Handling + für CLI-Tools, JSON/CSV, HTTP-Client, Pfad-/Verzeichnisfunktionen +- Verteilung: `tbdosc build --exe` als Single-File-Tool-Baukasten + +--- + ## Offene Fragen - Umgang mit `CURRENCY` (`@`): als i64-Festkomma (×10 000) — klären, ob das diff --git a/README.md b/README.md index a3cdf6a..e00baf4 100644 --- a/README.md +++ b/README.md @@ -1,12 +1,29 @@ # Terminal Basic -Eine plattformübergreifende Re-Implementierung des letzten großen BASIC-Dialekts +Eine plattformübergreifende **Re-Imagination** des letzten großen BASIC-Dialekts für DOS (1992) — Sprache, Laufzeitbibliothek, Forms-Engine und IDE — in Rust, mit [Ratatui](https://ratatui.rs) als Terminal-UI-Schicht. > Dieses Projekt ist eine unabhängige Neuentwicklung und steht in keiner > Verbindung zu Microsoft. Produktnamen Dritter werden bewusst nicht verwendet. +## Leitbild + +Terminal Basic ist keine sklavische 1:1-Reimplementierung, sondern eine +spirituelle Neuauflage: ein BASIC, mit dem man heute **Terminal-Tools baut** — +CLI-Werkzeuge ebenso wie TUI-Anwendungen. Der Weg dorthin: + +1. **Erst die Re-Imagination:** gleiche UI/UX wie das Vorbild, gleicher + Sprachstandard, gleiche Standardbibliothek. Wer das Vorbild kannte, fühlt + sich sofort zu Hause; bestehende Programme laufen weitgehend unverändert. +2. **Dann die Anreicherung:** über die Zeit kommen bewusst Elemente außerhalb + des Vorbilds dazu (moderne Terminal-Fähigkeiten, Sprachkomfort, + Bibliotheken). Erweiterungen sind additiv und brechen den Kernstandard + nicht. + +Wo Alt und Neu kollidieren, gewinnt die Plattform von heute — deshalb z. B. +durchgängig UTF-8 statt Codepage 437 und keine Emulation von DOS-Hardware. + ## Ziele - **Volle Sprachkompatibilität**: alle Sprachelemente des Dialekts — diff --git a/docs/tbvm-design.md b/docs/tbvm-design.md index b688866..01534a4 100644 --- a/docs/tbvm-design.md +++ b/docs/tbvm-design.md @@ -78,6 +78,39 @@ Ressource an (Anhängen ans Binary + Fußzeile mit Offset/Magic; portabel für alle drei Plattformen). Alternative — `include_bytes!` + Cargo-Build beim Nutzer — verworfen: erfordert Rust-Toolchain beim Anwender. +## Performance + +**Compiler (Instant-Compile, Anforderung siehe PLAN.md):** +- Single-Pass pro Modul: Lexen, Parsen und Codegen in einem Durchlauf; + Vorwärtsreferenzen (Prozeduren, Labels) über Fixup-Listen statt zweitem + Pass. Die Sprache ist dafür gemacht — das Vorbild kompilierte auf + 1992er-Hardware gefühlt sofort. +- Modulweise inkrementell: `.BAS`/`.FRM` werden unabhängig zu Bytecode- + Einheiten übersetzt und beim Build nur zusammengebunden; die IDE + recompiliert nur geänderte Module (Hash über Quelltext). +- Keine Optimierungspasses. Erlaubt sind nur Gratis-Optimierungen im + Codegen (Konstantenfaltung im Ausdruck, Peephole beim Emit). +- Budget als Test verankern (Phase 2): Benchmark-Projekt (~50k Zeilen) + muss unter 1 s kompilieren (Release-Build der Toolchain, Referenzrechner); + einzelnes Modul < 50 ms. + +**VM-Ausführung:** +- Alle Namen werden zur Compilezeit aufgelöst: Variablen/Parameter sind + Slot-Indizes, Prozeduren Tabellenindizes — zur Laufzeit keine + Hash-Lookups. +- Statische Typen des Dialekts ausnutzen: typisierte Opcodes + (`ADD_I16`, `ADD_F64`, `CONCAT` …) statt generischem Dispatch über + `Value`-Tags in heißen Pfaden. +- Dichte Opcodes, `match`-Dispatch in einer engen Schleife; Tick-Prüfung + (Events/Breakpoints) nur an Anweisungsgrenzen über ein einzelnes + Flag-Wort, nicht pro Opcode. +- Strings immutabel via `Rc` (Kopien sind Pointer-Kopien); + Konstantenpool dedupliziert. +- Messlatte (Phase 2, Benchmarks in `benches/`): typische + Schleifen-/String-Lasten mindestens ~100× schneller als das Vorbild auf + Originalhardware; Richtwert grob Lua-Interpreter-Klasse, gemessen und + dokumentiert statt geraten. + ## Offene Punkte - Opcode-Satz konkret ausformulieren (mit Phase 2)