Programmiersprache Extra Dry: Der Basic-Interpreter GFA-Basic 3.0 im Test

Als GFA-Basic auf den Markt kam, galt es als Sensation. Kein Wunder, denken Sie? Gegen das mitgelieferte ST-Basic bestach jede andere Programmiersprache. Als die Version 2.0 des GFA-Interpreters veröffentlicht wurde, hatte sich GFA-Basic als die meist verwendete Programmiersprache für den Atari ST etabliert. Die fast komplett neu entwickelte Version 3.0 soll alles Dagewesene in den Schatten stellen. Bei den vielen Programmiersprachen, die nun für den Atari ST angeboten werden, ein sehr schwieriges Unterfangen.

Bereits in der Juni-Ausgabe des ST-Magazins präsentierten wir Ihnen das neue GFA-Basic in der Version 3.0. Damals handelte es sich um eine nicht fehlerfreie Testversion, die GFA-Systemtechnik den Redaktionen der Computerzeitschriften zur Verfügung stellte. Seit Mitte Mai nun läuft die Auslieferung auf vollen Touren. Wir konnten die endgültige Version für Sie auf Herz und Nieren prüfen.

GFA-Basic 3.0 präsentiert sich in einem schwarzen Ordner, der jedoch im Gegensatz zur Verpackung der Vorgängerversion wesentlich dicker ausfällt. Der Ordner enthält die Programmdiskette und das neu abgefaßte Handbuch.

Zu einer Basic-Programmiersprache mit professionellen Ambitionen gehört unbedingt ein Handbuch, das Amateure und Profis gleichermaßen zufriedenstellt. Die etwa 550 Seiten des GFA-Basic-Handbuches sind in zwölf Kapitel unterteilt. Bereits die Einleitung beinhaltet Hinweise auf die herausragenden Eigenschaften des neuen GFA-Basic. Daran schließt sich eine gründliche Einführung in die Funktionen des Editors an.

In den folgenden zehn Kapiteln werden alle Befehle und Funktionen, nach Sachgebieten sortiert, ausführlich erläutert.

In dem Kapitel über die AES-Befehle sind sämtliche Strukturen des AES aufgeführt. Der Anhang befaßt sich mit den wenigen Inkompatibilitäten zwischen den Versionen 2.0 und 3.0.

Die folgenden Seiten enthalten Erklärungen zu allen Systemaufrufen . (GEMDOS, BIOS, XBIOS) einschließlich der Aufrufparameter aus dem Interpreter heraus. Diverse Tabellen (VT52-Codes, SCAN-Codes, ASCII, LINEA und so weiter) und ein alphabetisches Schlüsselwortverzeichnis runden den Anhang ab. Insgesamt macht das Handbuch einen äußerst professionellen Eindruck. Da die Informationen über die reine Beschreibung des Interpreters hinausgehen, erspart man sich häufiges Nachblättern in anderen Handbüchern.

Angesichts des Lieferumfanges von GFA-Basic 3.0 ist ein Preis von 198 Mark als sehr günstig anzusehen. Auch der Betrag von 70 beziehungsweise 140 Mark für den Umtausch der alten Versionen gegen das neue GFA-Basic ist nicht zu hoch angesetzt, bedenkt man, daß ein vollständig neues Produkt geliefert wird.

Trotz aller Verbesserungen und Erweiterungen blieb GFA-Basic 3.0 sehr kompakt. Der Interpreter umfaßt nur knapp 97 KByte. Zusätzlich befinden sich auf der Diskette verschiedene Beispielprogramme. Eine positive Überraschung stellt das mitgelieferte Resource-Construction-Set — Version von Digital Research — dar. Dieses Programm ist eine völlige Neufassung des Urvaters aller RCS-Programme. Ein Icon-Editor ist zwar immer noch nicht integriert, dafür arbeitet das Programm aber fehlerfrei.

Speziell für GFA-Basic 3.0 nahm man am RCS noch einige Änderungen vor. Die Headerdateien gibt es in dieser speziellen Version auch als ».LST«-Datei aus. Der Interpreter fügt die LST-Datei in das Programm ein. Ein Mangel des Original-RCS besteht darin, daß Objektnamen nur mit Großbuchstaben geschrieben werden dürfen. Andere RCS-Programme umgehen dieses Problem, indem sie Kleinbuchstaben umwandeln. Das gepatchte RCS nimmt auch Kleinbuchstaben an, da der Interpreter je nach Listmodus die Namen umwandelt.

Um GFA-Basic 3.0 ausgiebig zu testen, portierten wir ein größeres Programm, das wir mit GFA-Basic 2.0 entwickelt hatten, den speziellen Eigenschaften des neuen Basic an. Gleich beim Editor fallen einige Unterschiede zur Version 2.0 auf. Die gravierendste Erweiterung liegt in den einklappbaren Prozeduren. Lange Unterprogramme verschwinden auf Tastendruck bis auf ihre Kopfzeile vom Bildschirm. Die Übersicht steigt besonders bei langen Programmen beträchtlich. Sehr umfangreiche Programme sind übersichtlich geordnet und in wenigen Zeilen auf einen Blick zu lesen. Durch einen erneuten Druck auf die Taste <Help> erscheinen wieder alle Zeilen der jeweiligen Prozeduren wieder auf dem Bildschirm.

Häufig treten jedoch kleine Tücken an Stellen auf, wo man sie nicht vermutet. Nachdem ein 50 KByte langes Programm (es handelt sich um das Malprogramm »Denise«) erfolgreich umgesetzt und alle Prozeduren — etwa 80 — eingeklappt waren, zeigte sich noch ein Fehler im Programm. Das Programm veränderte eine globale Variable und produziert so Fehlermeldungen. Normalerweise ist es einfach, mittels der FIND-Funktion die fehlerhafte Stelle im Programm zu lokalisieren. Da der GFA-Editor jedoch in eingeklappten Prozeduren nicht sucht, erschwert sich die Fehlersuche in erheblichem Maße. Dieselbe Tücke zeigte sich bei dem Versuch, das Programm auf einem Drucker zu listen. Aus den etwa 45 Seiten wurden plötzlich zwei Seiten, von denen 80 Zeilen nur »PROCEDURE...« enthielten. Dies läßt sich umgehen, indem man das Programm als ASCII-Listing speichert und anschließend zum Beispiel mit Hilfe einer Textverarbeitung druckt. Dabei geht jedoch die Wirkung der vom GFA-Editor verarbeiteten Punktbefehle zur Druckersteuerung verloren. Wünschenswert wäre ein Befehl, der alle Prozeduren auf Tastendruck aufklappt.

Sehr hoch einzuschätzen ist die neue Tastaturbelegung des GFA-Basic 3.0. Häufig benutzte Tastaturkommandos wie »Zeilen löschen« oder »Block markieren« entsprechen nun den geläufigen Kommandos der meisten Editoren und Textverarbeitungen. Der eingefleischte C- oder Assembler-Programmierer kann ohne große Umstellung seine Programme in den GFA-Basic-Editor »einhacken«. Hinzugekommen ist auch eine Tastenkombination, die die zuletzt gelöschte Zeile an der aktuellen Cursorposition einfügt. Dank dieser Funktion ist man auf einfache Weise in der Lage, einzelne Zeilen zu duplizieren oder zu verschieben.

Oft ist es wichtig, sich mehrere Stellen im Programm zu merken, um dort Änderungen vorzunehmen. Im Editor setzt man zu diesem Zweck mehrere Marken mit den Kontroll- und Zifferntasten. Drückt man gleichzeitig die Alternate- und eine Zifferntaste, springt der Editor an die entsprechende Marke.

Mit den bereits oben erwähnten Punktbefehlen ist man in der Lage, ein Druckerlisting zu formatieren. Die Punktbefehle lassen sich wie normale Befehlszeilen ins Programm einfügen, haben jedoch keinen Einfluß auf den Programmablauf, sie machen sich lediglich beim Ausdruck bemerkbar. Mit ihnen setzt man die Seiten- und Zeilenlänge und bestimmt den Inhalt von Kopf- und Fußzeile jeder Seite. In diese Zeilen lassen sich auch Uhrzeit, Datum und Seitennummer eintragen. Lange Listings geraten so übersichtlich, gut lesbar.

Etwas störend wirkt sich das »Prellen« der Maustasten aus. Aktiviert man eine Dialog-, Alert- oder auch die Fileselectorbox, verhält sich das Programm so, als würde man den linken Mausknopf permanent gedrückt halten. Erst wenn man den Knopf tatsächlich betätigt, hat das Spiel ein Ende. Nach Aussage von Frank Ostrowski, dem Entwickler des GFA-Basic, handelt es sich hierbei um eine üble Laune des AES. Da jedoch im GFA-Basic 2.0 dieses Phänomen — zumindest im Editor — nicht auftrat, darf Hoffnung aufkeimen, daß in diesem Punkt noch Abhilfe zu schaffen ist.

Ein großes Manko des bisherigen Editors war die fehlende Accessory-Leiste. Der jetzige Editor verfügt zwar auch nicht über diese Leiste, Accessories lassen sich also daraus auch nicht aufrufen. In die linke, obere Ecke plazierte Ostrowski ein Atari-Zeichen. Klickt man darauf, wechselt man damit in einen Desktop mit Menüleiste. Steuert man den Mauszeiger auf den linken Menüeintrag, erscheinen die Namen der geladenen Accessories.

Zurück zur Anpassung von Denise an GFA 3.0. Das Programm ist nun fertig eingelesen, geändert und eingeklappt, mit der gewohnten Tastenkombination <Shift-F10> gibt man dem Programm das Startsignal und erlebt die erste angenehme Überraschung: Es läuft! Kreise und Linien zeichnen, Bilder laden und Blöcke biegen, alles verrichtet seinen Dienst in gewohnter Manier. Von irgendwelchen Inkompatibilitäten nicht die geringste Spur!

Erst nach einiger Zeit angestrengter Fehlersuche erscheint auf dem Bildschirm die Meldung »Zwei Bomben...«, die einen Busfehler des Prozessors signalisiert. Nach dem Quittieren der Meldung tastet man sich im Editor an die Zeile heran, bei deren Abarbeitung der Fehler auftrat. Es offenbart sich ein kleiner Unterschied zu GFA-Basic 2.0. Fügt man nämlich im alten Basic an den PUT-Befehl einen Leerstring an, geschieht nichts weiter. GFA-Basic 3.0 dagegen produziert den oben beschriebenen Fehler. Während der Testphase blieb dies der einzig inkompatible Befehl.

Die nächste Testphase testete die neuen Funktionen des Interpreters weitestgehend aus. Das Malprogramm Denise steuert der Anwender über Pull-Down-Menüs.

Die mit GFA-Basic 3.0 programmierbare SELECT-CASE-Anweisung läßt folgende Fallunterscheidung zu:

SELECT MENU(0)
CASE 1
	(Weitere Befehle)
CASE 2
	(Weitere Befehle) 
ENDSELECT 

Mit zunehmender Anzahl von Fallunterscheidungen steigert sich auch die Effektivität der SELECT-CASE-Anweisung. Der Vorteil liegt jedoch nicht nur in der Programmkürze, sondern auch in der Laufgeschwindigkeit. Nach erfolgreichem Abarbeiten einer CASE-Anweisung springt ein GFA-Basic 3.0-Programm nämlich sofort zur ENDSELECT-Zeile.

Ein Nachteil der SELECT-CASE-Anweisung besteht darin, daß man nur arithmetische Ausdrücke und Strings bis zu einer Länge von vier Zeichen als Kriterium benutzen kann. Doch auch für den Fall, daß dies nicht ausreicht, ist vorgesorgt. Mit der neuen ELSE IF-Anweisung lassen sich ähnliche Fallunterscheidungen aufbauen wie mit SELECT-CASE, bei diesen darf man aber beliebige Ausdrücke verwenden.

Viele Unterprogramme liefern einen Wert an das aufrufende Programm zurück. Dies geschah bisher über globale Variablen oder aber mit Hilfe von Zeigern. Die erste Art ist wenig elegant und die zweite stellt sich teilweise sehr mühsam dar. Beide Lösungen besitzen den Nachteil, daß die Unterprogramme nicht wie Funktionen oder Variablen in Berechnungen zu verwenden sind. Mit GFA-Basic 3.0 gehören diese Probleme der Vergangenheit an.

Unterprogramme können jetzt auch als Funktionen deklariert und wie echte Funktionen — etwa SIN() oder LEFT$() — eingesetzt werden. Als Beispiel dient eine Alternative zum FILESELECT-Befehl:

FUNCTION fileselect$(pfad$,datei$)
	LOCAL Kennung$
	FILESELECT pfad$,datei$,Kennung$
	RETURN Kennung$
ENDFUNC

Nun läßt sich die Fileselectorbox wie in folgenden Beispielen benutzen:

OPEN "I", #1,@fileselect$( "A:\k.DAT", "TEST.DAT") 

oder

compare_files(@fileselect("*.*", ""),@fileselect("*.*", ""))

Ein weiteres Bonbon für die Unterprogramm-Definition stammt eindeutig aus der Programmiersprache Pascal. Mittels der Ergänzung VAR im Prozedurkopf übergibt man Unterprogrammen statt des Variablenwerts eine Variable. Ändert sich der Wert dieser Variablen innerhalb der Prozedur, so ändert sich auch der Wert im auf-rufenden Programm. Durch diesen Trick lassen sich größere Listen mit Rückgabewerten verwirklichen (der Befehl FUNCTION gibt ja nur einen einzigen Wert zurück). Folgende Prozedur setzt alle Zahlen größer 100 im übergebenen Array auf Null:

PROCEDURE loesch(VAR x()) 
	LOCAL i%
	FOR i%=0 TO DIM?(x())
		IF x(i%)>100 
			x(i%)=0 
		ENDIF 
	NEXT i%
RETURN

Im aufrufenden Programm ist das Array ebenfalls geändert. Die Variablenübergabe mit VAR ist auch auf Funktionen anwendbar.

Durch die neuen Fähigkeiten von GFA-Basic 3.0 wurde nach und nach die gesamte Unterprogrammstruktur des Programms Denise überarbeitet. Die meisten globalen Variablen entfielen, so daß das Programm eine erheblich klarere Struktur erhielt.

Die Einbindung von Assembler-Routinen oder anderen Binärdaten stellte mit GFA-Basic 2.0 noch ein Problem dar. Entweder mußten die Daten mit BLOAD nachträglich geladen werden oder aber sie wurden in DATA-Zeilen gepackt. GFA-Basic 3.0 bietet dagegen als neue Alternative den INLINE-Befehl. Mit seiner Hilfe lassen sich Binärdateien direkt in das Programm integrieren. Die Daten sind nun ein fester, wenn auch unsichtbarer Bestandteil des Programms. Ein dafür eingerichtetes Menü erlaubt es, die Daten in einem INLINE-Befehl zu laden, zu speichern, zu löschen und auf einem Drucker zu listen. So baut man ganze Bilder ins eigene Programm ein.

Der nächste Schritt der Anpassung war eher kosmetischer Natur. Das Malprogramm Denise benutzt sehr viele selbstkonstruierte Dialog- und Auswahlboxen, die es mit zahlreichen Grafikbefehlen auf den Monitor schreibt. Entsprechend umständlich stellt sich anschließend die Abfrage dieser Boxen dar, da man anhand der Mauskoordinaten selbst ermitteln muß, welches Objekt gerade angesprochen wird.

	GFA-Basic 3.0	GFA-Basic 2.02	GFA-Basic Comp. 2.02	Omikron-Basic 2.2	Omikron-Basic 2.4 (Comp.)	ST-Pascal 2.02	Pro Fortran 2.1	Megamax C 1.1
Sieb des Eratosthenes	43	58,9	13,0	34,8	2,5	5,4	4,8	4,0
Savage (5000mal)	39,5	31,5	27,9	156,4	153,2	157,1	104,2	>1000
Abweichung	1E-6	2E-4	2E-4	8E-9	8E-9	5E-1	6E-7	2E-7
leere Prozedur	8,9	11,9	4,1	17,5	1,2	2,4	2,5	1,3

In GFA-Basic 3.0 sind nunmehr sämtliche AES-Aufrufe implementiert, so daß es sich anbietet, ein wenig mit den GEM-Objekten herumzuspielen. Wir konstruierten mit dem Resour-

Michael Bernards

---

---