Im RISC OS Open-Forum läuft gerade eine Diskussion zum Thema BBC BASIC und der Verfügbarkeit von BASIC-Compilern. Eigentlich trage ich mich schon länger mit dem Gedanken, einen Blog-Eintrag mit dem Thema „BBC BASIC – Fluch und Segen für RISC OS“ zu verfassen. Die Diskussion hat mich nun dazu motiviert, weniger negativ („Fluch“) über die Sache zu denken, sondern die Chancen darin zu sehen.
In der RISC OS-Welt hat BBC BASIC eine besondere Stellung. Vom BBC Micro über den Acorn Archimedes bis zum neuesten Titanium oder Raspberry Pi steckt der BBC BASIC-Interpreter überall standardmäßig drin. Die Handbücher früher beschrieben ausführlich den Einstieg in die Programmierung mit BBC BASIC. Letztlich war also BBC BASIC für viele RISC OS-Benutzer der erste Kontakt mit Softwareentwicklung. Jemand, der für RISC OS programmiert und nicht BBC BASIC kennt, ist quasi undenkbar.
Regelmäßig auftauchende Fragen sind: Ich habe BBC BASIC nun gemeistert, wohin als nächstes? Ich will ein komplexes Stück Software entwickeln, BBC BASIC erscheint mir dafür nur begrenzt geeignet, was verwende ich stattdessen? Unglücklicherweise gibt es unter RISC OS mehr oder weniger nur eine Antwort: C. Mit Einschränkungen auch C++. Alternativen mit Exoten-Status sind Lua und Charm. Das war’s dann aber.
Nach meiner Erfahrung gibt es nur wenige, die den Sprung von BBC BASIC nach C vollziehen – zu unterschiedlich die Konzepte, die Syntax, dazu die Umstellung vom Interpreter zum Compiler. Man profitiert eben kaum von seiner gesammelten Erfahrung mit BBC BASIC.
Nun ist es leider so, dass der BBC BASIC-Interpreter noch stark in den 80ern verhaftet ist. Der leistungsfähigste unterstützte Datentyp ist das Array. Strings sind auf 255 Zeichen Länge limitiert (und single byte encoding natürlich). Records kann man nur quasi-händisch über Speicherblocks simulieren. Die Abstraktionsmöglichkeiten enden bei den Konstrukten Prozedur und Funktion. Die Verwendung von C-Bibliotheken ist faktisch nur möglich, wenn diese in ein Modul mit SWI-Interface überführt werden. Unnötig zu erwähnen, dass man keine RISC OS-Module in BASIC schreiben kann. Dazu die typischen Interpreter-Probleme wie suboptimale Performance und fehlender globaler Syntaxcheck – besonders lustig, wenn man im Error-Handler einen Syntaxfehler eingebaut hat.
Könnte man den BBC BASIC-Interpreter denn erweitern? Bisherige Erfahrungen zeigen: sehr schwierig, vor allem wenn man die Rückwärtskompatibilität erhalten will. Basalt von Steve Drain versucht sich an diversen Erweiterungen, m.E. aber mit syntaktisch schwer verdaulichem Ergebnis.
Ausgehend von diesen Überlegungen rege ich (nach dem großen Erfolg der Ideen „Ein kompetenter Browser“ und „Qt portieren“) die Entwicklung eines BASIC-Compilers an. Das Potenzial der vielen kundigen BBC BASIC-Codern wird im Moment verschleudert durch die vielen Einschränkungen des Interpreters.
Wie könnte man dieses Projekt angehen? Am besten nicht nach der typischen RISC OS-Art, unter Vermeidung aller „not-invented-here“-Komponenten eine 100% hausgemachte Lösung zu brauen. Ziel muss es sein, eine dauerhafte Lösung zu bauen, die ohne größere Schmerzen es erlaubt, auch die nächsten paar ARM-Generationen zu überleben (man erinnere sich an die bisherigen Herausforderungen: StrongARM, 32bit, ARMv7). Also sollte man bestrebt sein, die Komplexität der eigentlichen ARM-Code-Erzeugung den Tools zu überlassen, die sowas schon seit langem beherrschen und aller Wahrscheinlichkeit nach das auch in Zukunft können werden.
Dazu gibt es prinzipiell zwei denkbare Wege: entweder, man übersetzt den BASIC-Code in C-Code und ruft dann einen C-Compiler auf, oder man implementiert ein neues Frontend für GCC. Für ersteres gibt es Beispiele für andere BASIC-Dialekte – BCX oder BaCon. Sogar in der RISC OS-Welt gibt es einen solchen Ansatz mit BBC_C32. Für letzteres gibt es meines Wissens keine frei verfügbaren Beispiele, aber jede Menge Dokumentation wie man derartige Frontends baut.
Was sollten die ersten Ziele sein? Die Unterstützung von etwas, was ich „well-formed BBC BASIC“ nennen würde. Also für das, was vernünftige Menschen in BBC BASIC programmieren würden, nicht für Code, der aussieht, wie wenn er durch einen zu intelligenten BASIC-Cruncher gelaufen wäre. Sogar das Nachdenken über Unterstützung von EVAL sollte unter Strafe gestellt werden. Der ARM-Inline-Assembler ist IMHO zu Anfang ebenso verzichtbar. Über eine stringentere Fassung des Typsystems sollte man nachdenken. Unterstützung für beliebig lange Strings sollte automatisch abfallen. Konstanten sollten möglich sein. Also kurz: alles, was „programming in the small“ ausmacht. Schleifen, Entscheidungen, Prozeduren, Funktionen.
Was stünde langfristig auf dem Plan? Unterstützung für Record-Strukturen, anständiges Speichermanagement (dynamische Allokation und auch Freigabe statt des statischen DIM-Zeugs), Unterstützung für weitergehende Abstraktion möglicherweise sogar objektorientierter Natur, sinnvolle Erweiterungen in punkto Sichtbarkeits- und Gültigkeitsregeln, Unterstützung für Modularisierung (Erweiterung des LIBRARY-Konzepts), Unterstützung zum Bau von RISC OS-Modulen, Integrationsmöglichkeit von C-Bibliotheken. Vielleicht sogar eigene Schlüsselwörter zur WIMP-Programmierung?
Also, die Vorarbeit ist geleistet, die Finalisierung überlasse ich wie immer gerne anderen. Für Syntaxvorschläge stehe ich gerne zur Verfügung.
Übrigens gab es über die Jahrzehnte durchaus bereits Versuche, BASIC-Compiler am Markt zu etablieren. ABC („Archimedes BASIC Compiler“, bis heute Teil des RISC OS DDE), RiscBASIC, HelixBasic, WimpBasic. Die Ergebnisse waren wenig überzeugend – zu gering der Performance-Vorsprung, und der Versuch, BBC BASIC möglichst präzise zu emulieren, verurteilte die Versuche zum Scheitern. Mit Blick auf die Microsoft-Welt könnte man sagen: VisualBasic wurde nicht deshalb so erfolgreich, weil es möglichst weitgehend QBasic-kompatibel war.