Basic-Compiler für Schneider CPC
Der Traum eines jeden Basic-Programmierers: Sobald ein Programm fertiggestellt und ausgetestet ist, übersetzt es ein Compiler in schnellen Maschinencode. Wir haben uns drei Basic-Compiler für die Schneider CPC-Serie angesehen.
Compiler übertragen Programme einer höheren Programmiersprache wie beispielsweise Basic, Pascal oder C in den vom Prozessor direkt ausführbaren Maschinencode. Es gibt ganz klare Regeln, nach denen sich die Leistungsfähigkeit eines Basic-Compilers beurteilen läßt. Am wichtigsten ist, daß er möglichst den gesamten Befehlssatz des zum Computer gehörenden Basic-Interpreters versteht und in Maschinensprache umwandelt.
Der Hauptgrund für die Anschaffung eines Compilers ist meist die erwartete (und oft überschätzte) Geschwindigkeitssteigerung. Also heißt die zweite Bedingung: Schnell muß er sein und schnelle Programme erzeugen. Das Tüpfelchen auf dem »i« wäre dann noch ein hohes Maß an Bedienungsfreundlichkeit. Doch auf die kann man notfalls auch noch verzichten als Programmierer ist man ja so einiges gewohnt... Die Kontrahenten: Zum Test treten drei Compiler an, die den Anspruch erheben, äußerst leistungsfähig zu sein. Das deutsche Produkt »Taifun« ist der Nachfolger von »ISSCom«, einem der ersten Programme für den Schneider CPC. Der britische »Laser-Compiler« ist ein Programm aus einer ganzen Produktreihe. Neben dem Compiler gibt es noch »Laser-Basic« (Spiele-Basic) und »Laser-Genius« (Editor/Assembler). In letzter Minute erreichte die Redaktion der dritte Kandidat: Das Hisoft-»Turbo-Basic«.
Alles oder nicht?
Hoffnungen darauf, daß die Compiler den kompletten Befehlssatz des Locomotive-Basic verarbeiten, darf man gleich aufgeben. Sowohl »Taifun« als auch der »Laser-Compiler« und »Turbo-Basic« verarbeiten nur reine Integer-Arithmetik, Das heißt, daß alle Rechnungen ausschließlich mit ganzen Zahlen durchgeführt werden. »PRINT 4.8/2« ergibt folglich nicht »2.4«, sondern »2«. Es ist natürlich sehr bedauerlich, daß die beiden Compiler damit gerade für so zeitintensive Anwendungen wie komplexe mathematische Berechnungen praktisch unbrauchbar sind. Denn so fehlen natürlich alle Fließkomma-Funktionen wie SIN, COS, TAN oder LOG. Eindeutiger Vorteil dieser Integer-Compiler ist aber, daß sie sehr schnellen und kurzen Programmcode produzieren. Um beispielsweise die Inhalte der beiden Z80-Register HL und DE zu addieren, genügt ein einziger mnemoni-scher Rechenbefehl (ADD HL.DE) für ganzzahlige Arithmetik, während sonst bei Gleitkomma-Operationen aufwendige Programmroutinen benötigt werden. Dennoch ist das keine Entschuldigung. Schließlich könnte man ja über eine Compiler-Direktive oder über die Befehle DEFINT und DE-FREAL den Benutzer entscheiden lassen, welche Arithmetikroutinen er vorzieht: die schnellen, aber ungenauen ganzzahligen Routinen oder die exakteren, dafür aber Speicherplatz- und geschwindig-keits-»fressenden« Fließkomma-Unterprogramme. Weiterhin fehlen den Compilern alle Befehle, die nur im Direktmodus des Interpreters einen Sinn haben. Darunter fallen AUTO (automatische Zeilennumerierung), RENUM (Umnumerierung der Programmzeilen), LIST und EDIT (Editieren einer Programmzeile). Den Verlust dieser Kommandos kann man sicherlich verschmerzen, weil die Programme ja im Interpreter-Modus ausgetestet werden sollen und erst, wenn sie fehlerfrei laufen, compiliert werden. Manche Basic-Befehle sind in compiliertem Code auch nur sehr schwer zu realisieren, zum Beispiel CHAIN, MER-GE und ERASE, sowie die gesamte Fehlerbehandlung mit ON ERROR, ERR, ERL und RESUME. Ihre Verwendung beantworten die Compiler mit einer Fehlermeldung.
Der Taifun-Compiler wird auf einer Diskette ohne Speicherschutz geliefert. Er arbeitet speicherresident. Das bedeutet, daß der Compiler an das obere Ende des RAM-Speichers geladen wird und die Kontrolle an das Basic zurückgibt. Der Benutzer kann dann wie gehabt mit dem Interpreter arbeiten: Programme eingeben, laden, editieren, ablaufen lassen und speichern eben alles, was sonst auch möglich ist. Nur ist der freie RAM-Speicher für Basic um ein ganzes Stück geschrumpft. Immerhin belegt der Compiler selbst bereits runde 13 KByte. Im Endeffekt liegt die obere Speichergrenze ungefähr bei der Adresse 17000. Durch Drücken der kleinen ENTER-Taste im Zehnerblock der Tastatur erfolgt der Aufruf des Compilers. Er beginnt sofort mit der Übersetzung und bietet danach drei Menüpunkte an: Speichern oder Starten des Programms und Rückkehr ins Basic. Bevor man aber soweit kommt, ist es ein ziemlich weiter Weg. Denn allzu leistungsfähig ist der Syntax-Checker (er prüft die korrekte Schreibweise sämtlicher Basic-Befehle) des Compilers nicht gerade. So tauchen ab und zu völlig unmotivierte Fehlermeldungen auf.
Basic-»Orkan«
Neben dieser »Macke« versteht Taifun auch logische Ausdrücke nicht immer richtig. Komplizierte IF-THEN-Konstruktionen lassen sich oft nur über den Umweg einer Hilfsvariablen durchführen. Selbst eine Befehlsfolge wie beispielsweise »IF INKEY$="A" THEN ...« läßt sich nicht übersetzen. Auch Verschach-telungen mit mehreren »ELSE«- Abschnitten gestattet der Taifun-Compiler nicht. Einfache Minussymbole als Vorzeichen von Variablen oder mathematischen Ausdrücken sind nicht zulässig. Statt »B = -A« muß man also »B = 0-A« eingeben. Das ist zwar keine große Arbeit, aber trotzdem lästig. Als sehr ärgerlich muß man gar bewerten, daß Variablen nur an den ersten beiden Stellen ihres Namens erkannt werden. Damit ist der vom CPC gewohnte Komfort dahin...
Kurz gesagt, es ist mit etlichen Mühen verbunden, Programme im Original-Schneider-Basic für den Taifun-Compiler »mundgerecht« aufzubereiten. In einer ganzen Reihe von Fällen ist das sogar schier unmöglich. Wer allerdings Programme speziell compilierfähig schreibt, kann überraschend gute Resultate erreichen und sogar auf völlig neue Befehle zurückgreifen. Basic-Kommandos, die der Compiler aufgrund seiner eingeschränkten Befehlsstruktur nicht verarbeitet, sind nämlich mit neuen Funktionen belegt. So zeichnet DEG sehr schnelle Kreise nach einem Algorithmus, der auf dem Satz des Pytha-goras basiert. COS schaltet den Cursor ein und aus, CREAL ruft eine Maschinenroutine auf, wobei sogar Registerinhalte zu übergeben sind. ERL und ERR verschieben Speicherblöcke im RAM (vergleichbar den Z80-Befehlen LDIR und LDDR). Mit LINE läßt sich der Bildschirm in verschiedene Richtungen scrollen und MERGE bindet einzelne Maschinencode-Bytes in das compi-lierte Programm ein.
Auch völlig neue Befehle finden sich im Kommandovorrat des Compilers. Sie werden alle aus anderen Befehlsnamen zusammengesetzt, beispielsweise PLOT PAPER und PLOT PEN, die GRAPHICS PAPER und GRAPHICS PEN auf dem CPC 664 und CPC 6128 entsprechen. READ CHR$ simuliert COPYCHR$ auch auf dem CPC-464. PAPER ist nicht mehr nur ein Befehl, sondern auch eine Funktion: »PRINT PA-PER(#1)«. Dasselbe gilt auch für PEN und MODE. Alles in allem: »Taifun« ist ein Compiler für Tüftler und alle, die nicht unter Zeitdruck stehen. Wer dazu bereit ist, an seinen Programmen herumzubasteln, bis der Compiler sie versteht, kann gute Ergebnisse erzielen.
»Strahlender« Konkurrent
Einen gänzlich anderen Weg geht der Laser-Compiler. Hier wird zunächst der Quellcode das zu übersetzende Basic-Programm als ASCII-Datei auf der Diskette gespeichert. Den Compiler startet der Benutzer mit »RUN " comp "«, worauf dieser im Bildschirm-Dialog alle benötigten Daten abfragt. Der Compiler untersucht das Programm in zwei Durchläufen. Mehrfach muß man dazu die Compiler- und Datendisketten wechseln. Ein kleiner Tip am Rande: Einfacher ist es, die Compilerdiskette zu kopieren (nicht raub-zukopieren!) und auf dieser Arbeitsdiskette den Quelltext und das compilierte Programm zu speichern. Durch die Konzeption des Compilers nicht im Arbeitsspeicher, sondern auf Diskette zu übersetzen sinkt natürlich die Geschwindigkeit ganz erheblich. Dafür sind weitaus längere Programme zu compilieren.
Unerklärliche Schwierigkeiten
Die Zahl der nicht unterstützten Basic-Befehle ist geringer als beim »Taifun«. Zusätzlich besitzt dieser Compiler eine bessere Syntax-Prüfung. Manche tief verschachtelten IF-THEN-Konstruktionen verarbeitet er zwar auch nicht, im allgemeinen klappt es jedoch. Dafür verursacht der Compiler aber unerklärliche Schwierigkeiten mit dem Bildaufbau. Die Cursorpositionierung arbeitet oft nicht korrekt, so daß Bildschirmmasken zerstört werden. Leider konnten wir nicht ergründen, wodurch das Fehlverhalten verursacht wird. Auch tauchen von Zeit zu Zeit unerwartete »Run-Time«-Fehlermeldungen auf. Manchmal sind schon beinahe artistische Klimmzüge notwendig, um solche Klippen zu umschiffen. Abgesehen davon sind aber einige fertige Basic-Programme manchmal fast ohne Änderungen übersetzbar. Lediglich eine Voraussetzung ist unbedingt einzuhalten: In den Listings müssen alle Datenfelder dimensioniert sein. Das Locomotive-Basic erledigt das sonst automatisch, wenn die obere Feldgrenze unter dem Wert 10 liegt. Herausragende Eigenschaft des »Laser-Compilers« ist die Unterstützung der Basic-Erweiterung »Laser-Basic« aus dem gleichen Hause. Dieses Programm war schon Objekt eines ausführlichen Testberichts in der Ausgabe 6/86. »Laser-Basic« ist vollständig auf die Programmierung schneller Spiele ausgerichtet. Der »Laser-Compiler« übersetzt fast alle RSX-Befehle dieses Pakets in Maschinencode. Das ist vor allem interessant für Software-Autoren, die ihre Produkte unabhängig von »Laser-Basic« vermarkten wollen. Denn der Anwender benötigt selbstverständlich kein »Laser-Basic«-Paket, und die Laufzeitbibliothek des Compilers darf ohne Einschränkungen durch das Urheberrecht und völlig ohne Lizenzgebühren weitergegeben werden. Letzteres gilt übrigens für alle besprochenen Compiler. Das ist auch ein weiterer Vorteil compilierter Programme: Vor dem Ideenklau ist man recht gut geschützt, denn ohne den Quellcode ist die Funktion des Programms kaum mehr nachzuvollziehen. Einen besonderen Geschwindigkeitsgewinn gegenüber der interpretierten Version des Laser-Basic-Programms sollte man allerdings nicht erwarten. Denn bei den RSX-Befehlen handelt es sich bereits um optimierten Maschinencode, der auch durch die Compilierung nicht mehr schneller zu machen ist. Flinker wird aber alles, was nicht direkt mit den zusätzlichen Kommandos von »Laser-Basic« zusammenhängt, also Variablenzuweisungen, Befehle zur Programmsteuerung, mathematische Routinen und was sonst noch zu Programmen gehört.
Ein »Meisterstück« haben die Hersteller des Programms mit der Bedienungsanleitungvollbracht. Sie ist zwar das ist sehr löblich neben Englisch auch in Französisch und Deutsch gehalten. Nur ist man beim Übersetzen über das Ziel hinausgeschossen. Ein kleines Zitat als Kostprobe mag das beleuchten: »Versuchen Sie, nicht zu viele Reihenkonstanten zu verwenden, da der Kompilierer keine Unratsammlung durchführt«. Es geht hier ganz einfach darum, nicht übermäßig viele Strings zu benutzen, weil die Laufzeitroutinen keine Garbage-Collection durchführen... Oft ist es tatsächlich einfacher, die englischsprachige Anleitung zu lesen!
Neue Besen kehren gut
Schon auf der Amstrad-Consumer-Show im Januar dieses Jahres gab es die ersten Ankündigungen des Hisoft-»Turbo-Basic«-Compilers. Er sollte bis auf die Verarbeitung der Fließkomma-Arithmetik sämtliche Basic-Funktionen beherrschen. Also verarbeitet er fast alle vorhandenen Programme ohne jegliche Änderung? Weit gefehlt! Das geringste Übel ist noch die Anpassung der RND-Funktion an den Compiler. Da er ja bekanntlich nur ganze Zahlen verarbeitet, ergibt RND Werte im Bereich von 0 bis 32767. Auch die anderen (im Handbuch beschriebenen) Änderungen (DIM ist unbedingt notwendig, RESTORE arbeitet nur mit Zeilenangabe, etc.) sind relativ leicht zu realisieren.
Die großen Schrecken kommen erst beim Compilier-Vorgang. Abbrüche mit Fehlermeldungen sind da noch die harmlosesten Situationen. Oft ist in einem solchen Fall Abhilfe zu schaffen. Wenn der Computer beispielsweise die Meldung »Expression too complex« (zu viele logische Vergleiche innerhalb einer Programmzeile) ausgibt, ersetzt man diesen Teil einfach durch andere Programm-Konstruktionen. Ratlosigkeit greift jedoch um sich, wenn der Compiler Fehler meldet, die es eigentlich gar nicht gibt!
So war während des Tests einmal auf dem Bildschirm »Illegal Code generated« zu lesen. In diesem Fall hält die übrigens englische Anleitung tröstende Worte bereit. Zitat: »Interner Compiler-Fehler, der niemals auftreten dürfte. . .«. Noch heimtückischer sind freilich Konstellationen, die den Computer während der Compilierung zum Absturz bringen; natürlich ohne jegliche Fehlermeldung. Da gibt es nur eines: in detektivischer Manier den Auslöser dieser Misere ausfindig zu machen. Als einen der Missetäter machten wir SPACE$ aus, obwohl dieser Befehl laut Bedienungsanleitung zum Wortschatz des Compilers gehört. Hat man aber solche »Stolpersteine« aus dem Weg geräumt und läßt dem Compiler freien Lauf, kommt man beim anschließenden Lauf des fertigen Maschinencodes aus dem Staunen nicht mehr heraus. »Turbo-Basic« hat zwar nicht so grundsätzliche Probleme mit der Bildschirm-Behandlung wie der »Laser-Compiler«, Programmblöcke mit reichlicher Verwendung von PEN, PAPER, INK und PRINT bringen ihn jedoch mitunter etwas aus dem Tritt. Vom verworrenen Bild bis zum Systemcrash reicht das bunte Spektrum der möglichen Effekte.
Bei soviel Kritik (die ja in vielen Punkten auch für die beiden anderen Kontrahenten gilt) sollte man jedoch vor lauter Schatten das Licht nicht übersehen. Es gibt nämlich tatsächlich auch Basic-Programme, die ohne(!) Änderungen sofort problemlos laufen. Nimmt man die Programme hinzu, bei denen die oben genannten Einschränkungen berücksichtigt sind, kommt man durchaus zu erstaunlich vielen »Erfolgserlebnissen«.
Auch das »Turbo-Basic« ist problemlos kopierbar und erzeugt völlig selbständig lauffähige Maschinencode. Als einziger der Testkandidaten bietet es zwei verschiedene Arbeitsmodi zur Wahl: Speicherresident lassen sich die Programme mit dem Interpreter bequem austesten, bevor man mit dem RSX-Kommando MAKE die Übersetzung veranlaßt. Mit dem Befehl COMPI-LE startet man die Compilierung auf Diskette, wobei das Quellprogramm nicht als ASCII-Datei vorliegen muß. Somit vereint »Turbo-Basic« in dieser Beziehung die Vorteile der beiden anderen Kandidaten.
Noch keine Perfektion
Perfekt sind die vorgestellten Compiler wahrlich nicht. Es gibt bei den drei Programmen so viele unterschiedliche Einschränkungen, daß es schwierig ist, einem den Vorzug zu geben. Der »Taifun« ist sehr wählerisch bei der Syntax der zu compilierenden Programme, während »Laser-Compiler« und »Turbo-Basic« die Programme scheinbar korrekt übersetzen und das ist besonders tückisch , dann aber nicht richtig abarbeiten. Solange es noch kein besseres Produkt gibt, muß man sich wohl mit einem dieser beiden Programme zufriedengeben. Wer über genug Zeit und Ausdauer verfügt, kann durchaus Programme in compilierbarer Form schreiben. »Taifun« und »Turbo-Basic« sind einfacher zu handhaben, weil sie im Speicher stets verfügbar sind und durch ihre hohe Übersetzungs-Geschwindigkeit beinahe schon Interpreter-Qualitäten besitzen. Dafür verarbeitet der »Laser-Compiler« zusätzlich die »Laser-Basic«-Befehle, die sehr leistungsfähig sind und beispielsweise Sprite-grafik überhaupt erst möglich machen.
Der Geschwindigkeits-Vergleich mit einem Programm, das die ersten 1479 Primzahlen berechnet, ergab recht gravierende Geschwindigkeitsunterschiede sowohl bei der Compilierung als auch in der Laufzeit (siehe Tabelle).
Natürlich spielen bei der Kaufentscheidung auch die Preise eine nicht unerhebliche Rolle. »Taifun« kostet für den CPC 464 knapp 125 Mark und für CPC 664 und 6128 etwa 140 Mark. Der »Laser-Compiler« war zum Zeitpunkt des Tests noch nicht in Deutschland lieferbar. Umgerechnet dürfte der Preis für die Kassettenversion zirka 80 Mark (Diskette 100 Mark) betragen. Auch »Turbo-Basic« ist noch nicht auf dem deutschen Markt erhältlich. Voraussichtlich wird es ungefähr 100 Mark kosten.
Benchmark-Test der Basic-Compiler
Compiler Compilieren Arbeitsweise Laufzeit Taifun unter 1 Sekunde nur im RAM 3,01 Sekunden Laser zirka 30 Sekunden nur auf Diskette 6,23 Sekunden Turbo-Basic unter 1 Sekunde im RAM 4,39 Sekunden zirka 12 Sekunden auf Diskette
Martin Kotulla/ja