GFA-Basic-Compiler: Ungebremstes GFA-Basic

Der Compiler zum GFA-Basic 3.0 hält, was er verspricht

Vor etwas mehr als einem Jahr stellte die Düsseldorfer Softwareschmiede GFA-Systemtechnik die Version 3.0 ihres in der Atari-Welt sehr verbreiteten Basic-Interpreters vor. Der zugehörige Compiler wurde für den Herbst 1988 angekündigt. Die parallel laufende Entwicklung des Basic-Interpreters für den Amiga erwies sich scheinbar aufwendiger als geplant, so daß der Compiler erst jetzt erhältlich ist.

Zum Lieferumfang gehören eine Diskette und ein 80seitiges Handbuch. Ein Blick ins Handbuch zeigt sofort, daß die Komplexität des neuen Compilers die der Vorgängerversion (V2.02) weit übersteigt. Wie bei anderen Sprachen sind neben dem eigentlichen Compiler auch ein Linker und Libraries enthalten.

Das Erscheinungsbild des Compilers weicht völlig von dem seines Vorgängers ab. Den alten Compiler bediente man über eine Dialogbox, den neuen steuert man über ein Shellprogramm. Die Funktionen dieser Shell sind auf ein Mindestmaß beschränkt, um nicht zu viel Speicherplatz zu verbrauchen. Da ihr Quelltext mitgeliefert wird, steht einer individuellen Erweiterung zur »Luxus-Shell« nichts im Wege. Starten Sie die Shell, erscheint eine Menüleiste und eine kleine Dialogbox auf dem Bildschirm. Die Box zeigt die aktuellen Compiler- und Linkerparameter und den Namen der Basic-Datei, mit der gearbeitet wird.

Die Shell verfügt über eine Menüleiste, deren Einträge Sie auch über Tastenkombinationen aufrufen. Im Menü »FILE« starten Sie Compiler, Linker, Interpreter und das Compilat. In einer etwas erweiterten Version der Shell, die ebenfalls zum Lieferumfang des Compilers gehört, starten Sie hier auch das mit dem Interpreter gelieferte Resource Construction Set und beliebige andere Programme.

Im »OPTIONEN«-Menü stellen Sie die Compiler- und Linker-Schalter ein, sofern Sie dies nicht schon im Quelltext erledigt haben. Ein Mangel an Schaltern ist nicht zu beklagen. Beispielsweise schalten Sie hier die verschiedenen Interrupt-Routinen an oder aus, die in einem GFA-Basic-Programm laufen, beispielsweise EVERY und AFTER und Floskeltasten.

Mit zwei weiteren Einträgen in diesem Menü legen Sie fest, ob der 68000-Befehl »MULS« oder eine eigene Routine die Multiplikation und Division von Integerzahlen erledigt. Ersteres bietet einen eindeutigen Geschwindigkeitvorteil, die Faktoren dürfen jedoch 32767 nicht überschreiten. Die SELECT-CASE-Anweisung läßt sich ebenso wie der RC INTER SF.CT-Befehl wahlweise auf 16-Bit-Verarbeitung optimieren. Bei der Programmierung von Accessories ist das Reservieren von ausreichend Speicherplatz besonders wichtig. Dazu teilen Sie dem Compiler durch den Schalter »Memory« mit, wieviel Speicher das compilierte Programm nach seinem Start belegt.

Schalter im Basic-Quelltext

»E$« und »E # « bestimmen, ob Fehlermeldungen als Zahlen oder im Klartext erscheinen. »$B+« führt dazu, daß der Compiler die berüchtigten »Bomben« des Betriebssystems abfängt und statt dessen Fehlertexte ausgibt.

Neben den Schaltern, die Sie in der Shell einstellen, verarbeitet der Compiler noch weitere, die Sie nur im Quelltext setzen können. Dies ist immer dann nötig, wenn sich eine Einstellung nicht auf das gesamte Programm bezieht, sondern nur auf einen bestimmten Abschnitt des Listings.

Mit dem Schalter »$X« binden Sie Unterprogramme anderer Sprachen in Ihre GFA-Basic-Listings ein. Hinter diesem Schalter geben Sie den Namen der einzubindenden Prozedur an. Der Linker verlangt nur noch den Namen der Bibliothek oder des Objektcodes. Schon gliedert sich dieses Unterprogramm als Bestandteil des Programms ein. Dies wird besonders Programmierer freuen, die auch Programme in anderen Sprachen entwickeln. Sie müssen nun nicht mehr in GFA-Basic-Routinen zum zweiten Mal formulieren, sondern binden sie in ihr Basic-Programm ein.

Unter dem dritten Eintrag »SETS« erledigen Sie diverse Systemeinstellungen. Hier geben Sie die Namen der erzeugten Objektdateien und Programme an. Die erweiterte Version der Shell gestattet es, daß das Programm automatisch den Namen der Quelldatei übernimmt.

Um die Turn-Around-Zeiten kurz zu halten, lädt der Compiler bei seiner Arbeit die Quelltexte vollständig, bevor er sie übersetzt und das ausführbare Programm speichert. Da dies aber bei STs mit kleinem Speicher bei größeren Programmen zu Problemen führt, erlaubt ein Flag, bereits übersetzte Prozeduren aus dem Speicher zu entfernen.

Bei einem Basic-Compiler ist die Arbeitsgeschwindigkeit nicht so entscheidend wie beispielsweise bei einem C-Compiler, da die Programme mit einem Interpreter entstehen. Um so erfreulicher ist, daß der 3.0-Compiler gegenüber der Version 2.02 noch schneller wurde.

Wichtiger als die Compilergeschwindigkeit ist die Laufgeschwindigkeit der übersetzten Programme. Betrachten wir deshalb zunächst die Schleifenzuweisungen FOR-NEXT, REPEAT-UNTIL und WHILE-WEND. Der 2.02-Compiler erzeugte aus der REPEAT-UNTIL-Schleife den schnellsten Code. Jetzt übersetzt der Compiler alle Schleifentypen in das gleiche Maschinensprachenkonstrukt. Sie arbeiten also alle gleich schnell. Entnehmen Sie bitte der Tabelle die Rechenzeit für eine Leerschleife mit 25 000 Wiederholungen.

Die Geschwindigkeit steigt weiterhin, weil zur Laufzeit keine permanente Typen- und Überlaufüberwachung stattfindet. Ändert sich während der Laufzeit eine Integervariable, so prüft der Interpreter, ob der neue Wert der Variablen innerhalb des Zahlenbereichs dieses Variablentyps liegt. Ist dies nicht der Fall, so tritt ein Fehler auf, der sogenannte Integerüberlauf. In einem fehlerfreien Programm ist eine solche Prüfung nicht notwendig. Da Programme mit dem Interpreter entstehen, der alle Fehler meldet und erst dann compiliert, wenn sie fehlerfrei sind, ist eine Überwachung im compilierten Programm überflüssig.

In der Tabelle finden Sie einige Ergebnisse von Benchmarktests, die deutlich zeigen, wie stark der Compiler die Programme beschleunigt. Bemerkenswert ist, daß die Integerarithmetik bis zu Faktor 12 schneller ist als im interpretierten Programm. Sogar das Sieb des Erathostenes, ein Testprogramm, das feststellt, wie schnell die Rechenoperationen abgearbeitet werden, erreicht noch Faktor 9. Die Steigerungen bei Fließkommaberechnungen sind nicht so drastisch (siehe Savage-Test), erreichen aber auch teilweise Faktor 3, etwa bei der einfachen Addition.

Wem diese Geschwindigkeit nicht genügt, der entwickelt seine zeitkritischen Routinen in Assembler oder in C und linkt diese zum GFA-Basic-Programm. Der Compiler erzeugt DRI-kompatiblen Objektcode, der allerdings in komprimierter Form gespeichert wird. Das Handbuch beschreibt detailliert, wie Sie Turbo-C-Routinen und Libraries einbinden und aufrufen. Aber nicht nur das Schreiben eigener Routinen in anderen Sprachen ist wichtig. Betrachtet man, welche Libraries für andere Hochsprachen verfügbar sind, eröffnen sich für GFA-Basic-Programmierer ganz neue Schaffensgebiete. Denken Sie zum Beispiel an »Adimens-Prog«, eine Datenbank-Bibliothek, die den Grundstock der Datenbank »Adimens ST« bildet.

Apropos neu: Einen neuen Befehl bietet GFA-Basic seit der Version 3.07. Das Kommando »CURVE« erzeugt unter Angabe von vier Koordinaten auf dem Bildschirm eine Bezierkurve. Natürlich verarbeitet der Compiler auch diesen Befehl.

Vom Basic zum Accessory

Wir erwähnten bereits, daß der Compiler auch Accessories erzeugt. Dabei sind einige Besonderheiten zu beachten. Zunächst darf ein Accessory nach seinem Start nicht den gesamten Speicher belegen. Es ist daher mit dem Schalter »$mxxxx« zu compilieren, wobei »xxxx« die Anzahl der Bytes angibt, die dem Programm zur Verfügung stehen.

Ein Accessory reserviert sich zunächst in der Menüleiste einen Eintrag. Dies erledigt die Funktion MENU_REGISTER, mit der Sie die Applikationsnummer und den Menüeintrag an GEM übergeben. Die Applikationsnummer erhalten Sie mit der Funktion APPL_INIT.

Mit dem Wert, den APPL_INIT zurückmeldet, stellen Sie auch fest, ob das Compilat als Programm oder als Accessory gestartet wurde. Ein Wert ungleich 0 deutet auf die Applikationsnummer eines Accessories. Eine 0 weist auf ein Programm hin.

Niedrige Anschaffungskosten

Das Hauptprogramm eines Accessories besteht aus einer Endlosschleife, in der es auf einen Aufruf wartet. Dies erledigen Sie beispielsweise mit der Funktion EVNT_MESAG. Den Accessory-Aufruf erkennt das Programm am Wert 40. Diesen Wert schreibt GEM in den Ereignispuffer, wenn das Accessory angeklickt wurde. Unser kurzes Listing zeigt die nötigen Elemente eines Accessories, das auch als normales Programm lauffähig ist. In der Prozedur »Programm« steht nur ein Platzhalter für ein größeres Programm.

Erfreulich sind die niedrigen Anschaffungskosten des Compilers. Wer den Interpreter 3.0 besitzt, erhält den Compiler für 10 Mark. Aber auch die Unentschlossenen dürfen sich freuen, da der Interpreter zusammen mit dem Compiler ab sofort als GFA-Basic 3.0 erhältlich ist.

Zusammenfassend läßt sich feststellen, daß der 3.0-Compiler und seine Shell mit dem Interpreter ein leistungsfähiges Entwicklungspaket ergibt. Der neue Compiler erzeugt schnelleren und kompakteren Code als sein Vorgänger. Zusätzliche Fähigkeiten wie Linkfähigkeit und das Erzeugen von Accessories runden das Bild ab. Mit anderen Worten, der Aufstieg lohnt sich. (uh)

GFA Systemtechnik GmbH, Heerdter Sandberg 30-32, 4000 Düsseldorf 11

$ ml280	! Nur 1280 Bytes verwenden
ap id&=APPL INIT()	! Applikations-Identifikation
me id&=MENU REGISTER(ap	id&," Demo-ACC ")
IF ap_id&=0	! Falls als Programm gestartet
Programm	
END	
ENDIF	
DO	
~EVNT MESAG(0)	! Message-Buffer überwachen
IF MENU(1)=40	! Accessory wurde angeklickt
Programm	
ENDIF	
LOOP	
PROCEDURE Programm	
ALERT 1,"Hello world!	",1,"Return",a|
RETURN	

Ein Beispiel für die »Schalter« im GFA-Basic-Quelltext

Schleife	Version 2.0	Version 3.0
FOR-NEXT	4,27s	1,94s
REPEAT-UNTIL	2,07s	1,94s
WHILE-WEND	2,46s	1,94s

Benchmark	GFA Interpreter	Compiler	Omikron Interpreter	Compiler
Savage	34,9s	34,2s	22,5/154,8s	22,4/153,2 s
Sieb	54,0s	6,1s	34,8s	2,7s
Genau	2,58s	0,585s	4,0/4,5s	0,8/1,1 s

Michael Bernards Gottfried Engels

---

---