Licom - Das saubere GFA
Mit Licom wird ein Traum wahr: saubere und schnelle GFA-Kompilate.
Als GFA-Programmier hat man es nicht leicht: Zum einen spötteln Programmierer anderer Sprachen gerne über das angeblich unsaubere Basic, und zum anderen macht es sich ein GFA selbst auch nicht allzu leicht, denn es existieren unbestritten einige Bugs im Basic. Doch im Gegensatz zu PureC/Pascal & Co. wird GFA weiterentwickelt, zwar nicht von GFA Systemtechnik, aber von engagierten Programmierern. Jüngst wurde face-Value 2.3 präsentiert, und jetzt gibt es auch einen neuen Patch - und der hat es in sich: Licom.
Voraussetzungen
Licom läuft unter allen TOS-Versionen und Multitasking. Benötigt wird die ungepatchte Compiler-Library des GFA-Basic 3.6TT (in den meisten Fällen ist dies die GFA3BLIB). Ältere Versionen funktionieren zum einen nicht, zum anderen sollte man als GFA-Programmierer schon die letzte Version des Basics besitzen. Empfehlenswert ist weiterhin Ergo pro, worauf ich im Verlaufe dieses Artikels noch weiter eingehen werde.
Funktionsweise
Licom patcht die GFA3BLIB, die für das Compilieren eines Programmes benötigt wird. Diese sollte im unmodifizierten Zustand vorliegen, das setzt natürlich voraus, daß man sich ein Backup von der ungepatchten Datei gemacht hat. Die Licom patcht nur diese Datei und nicht etwa Interpreter/Compiler. Die GFA3BLIB sollte im gleichen Verzeichnis wie Licom liegen, die NDX-Datei wird nicht benötigt, da nach dem Patchen eine neue erzeugt wird.
Start
Nach dem Programmstart präsentiert sich Licom sehr übersichtlich in einem Dialog. Daß eine (stark) modifizierte faceValue-Version am Werk ist, merkt man schon an der fehlenden Menüleiste, die aber für so ein kompaktes Programm auch unangemessen wäre. Mit einem Klick auf "Script" kann eine Patch-Liste ausgewählt werden. Bei der Vielzahl an Patches wird vielleicht der eine oder andere nicht benötigt - kein Problem, denn die Licom-Scripte sind sehr einfach aufgebaut und zudem mit Kommentaren versehen. Ein zweiter Vorteil ist die Modularität: Jeder Patch liegt als eigene Datei vor, und so sind Updates sehr einfach möglich. Gleich nach der Auswahl des Scripts wird man aufgefordert, die GFA-Library auszuwählen. Sofort danach macht sich die Licom an die Arbeit und erzeugt danach die Index-Datei.
Patches
Die Patches lassen sich grob in fünf Gruppen unterteilen:
- Fehlerkorrekturen
- Geschwindigkeitsoptimierungen
- Verbesserung der Stabilität
- Umlenkung von Line-A auf "saubere" Funktionen
- Dummys.
Insgesamt liegen 48 Patch-Dateien in der v1.1 vor.
Böses, böses Line-A
Wer in älteren Atari-Büchern nachschlägt, wird auf Empfehlungen wie "Benutzen Sie Line-A, das ist schneller" gestoßen sein. Auch das GFA-Basic verwendet im ungepatchten Zustand intern Line-A-Aufrufe und baut diese in zuvorkommenderweise beim Compilieren in das eigene Programm mit ein. Line-A gilt aber mittlerweile als so ziemlich das schmutzigste, was man sich beim Programmieren leisten kann. Diese Betriebssystemfunktionen waren (und sind) nur für die ST-Auflösungen gedacht - mit Grafikkarten vertragen sie sich nicht und sind auch sonst ziemlich absturzträchtig. Von daher ist es oberste Pflicht eines jeden Patchprogramms, die Compilate Line-A ffeizuhal-ten.
Fehlerkorrekturen
Licom korrigiert neben den bekannten Fehlem auch sehr viele bisher unentdeck-te Bugs. Bei einigen ist jedoch zu beachten, daß sie nach wie vor im Interpreter nicht korrekt arbeiten, da natürlich nur das Compilat gepatcht wird. Was alles korrigiert wird, steht in einer separaten Datei, einige Befehle seien hier genannt: VSETCOLOR funktioniert auch mit mehr als 16 Farben (wenn auch nur im Kompilat). Bei INPUT wurden Hiide mouse/Show mouse Aufrufe entfernt, die auch nicht unbedingt für ihre Sauberkeit berühmt waren. Die DEF-Befehle (also DEFTEXT usw.) wurden von Line-A befreit. Bei der Programminitialisierung wurde ebenfalls Line-A entfernt und die Speicherinitialisierung verbessert. Die AES-Initialisierung hat ähnliche Korrekturen erfahren. Die Funktion TT? war bisher nicht besonders empfehlenswert, dank Licom kann man sie nun zum Erkennen der FPU gefahrlos benutzen, da Richard Gordon Faika diese völlig neu geschrieben hat(!).
Geschwindigkeitsoptimierungen
Auch hier hat sich einiges getan, denn Geschwindigkeitsverbesserungen gibt es u.a. bei folgenden Befehlen: DEFXXX, Initialisierungsroutine, RSRC_FREE(), GRAF_HANDLE(), GRAFMKSTATE() und EVNT_KEYBOARD(). Doch ein wahrer Knüller dürfte wohl die vollautomatische und saubere Unterstützung der FPU sein! So etwas ist auf dem Atari bislang wohl einmalig, denn ein mit der gepatchten Library compiliertes Programm erkennt selbständig eine vorhandene FPU und wird so unter Umständen dramatisch beschleunigt. Durch Programme, die sehr viel mit Befehlen wie SQR, MUL, ROUND und SIN arbeiten, werden Maschinen wie der Milan noch schneller. Laut Anleitung arbeiten die FPU-Befehle zum Teil bis zu zehnmal schneller.
Verbesserung der Stabilität
Die Stringverwaltung und mit ihr verbundene Befehle wie DIM und ERASE wurde in ihrer Stabilität verbessert. Es läßt sich zwar nicht leicht nachprüfen, wie oft die alte Stringverwaltung Probleme bereitet hat, aber vermutlich wird es dadurch einige überraschende Abstürze weniger geben, die GFA-Programmierem schon manche grauen Haare beschert haben. Auch der Init-Teil und DEFXXX-Befehle wurden auf Stabilität und Größe optimiert.
Umlenkung von Line-A auf "saubere" Funktionen
Einige ehemalige Line-A-Funktionen wurden auf VDI-Funktionen umgelenkt, doch längst nicht alle. In GFA-Hypertexten befinden sich jedoch oftmals Tips, wie man dieses Befehle gegen saubere Versionen ersetzen kann. DEFMOUSE wurde auf eine AES-Funktion umgelenkt, ebenso wie PSET. Da DEFMOUSE gerne in älteren Programmen verwendet wurde, ist dies sicherlich eine praktische Sache. Die Gruppe der MOUSE-Befehle (MOUSE, MOUSEX, MOUSEY, MOUSEK) ist jetzt auch AES-konform. Allgemein läßt sich sagen, daß zumindest die Line-A-trächtigen Befehle, die gerne in älteren Programmen auftauchten, auf saubere AES-Aufrufe umgelenkt wurden. Der Rest wurde durch Dummyfunktionen ersetzt, so daß sie zumindest keinen Schaden anrichten können.
Dummys
Folgende Line-A-Befehle wurden durch Dummys ersetzt: ACLIP, ALINE, APO-LY und ARECT. Das gleiche Schicksal haben GET, PUT sowie SGET und SPUT erlitten, wobei damit nur die Verwendung für den Bildschirm gemeint ist. Im Hypertext GFA-Utilities gibt es einiger Ersatzfunktionen für die GET- und PUT-Befeh-le, damit diese auch mit hohen Auflösungen zurechtkommen. PTST, RC COPY und SPRITE haben in modernen Programmen nichts zu suchen und werden auch durch Dummyfunktionen ersetzt. Ähnliches gilt für die GFA-Window-Befehle wie OPENW, die nicht nur sehr unflexibel, sondern auch unsauber sind. Als Alternative bieten sich die Routinen von faceValue an.
Weitere Extras
Hat man sein nun compiliertes Programm endlich zum Absturz gebracht (was schwer genug ist), zeigt sich eine weitere Neuerung: die neue Error-Verwaltung, die mehr Informationen über die Art des aufgetretenen Fehlers bietet. Zwar muß man als Programmierer auch aus solchen Meldungen erst einmal schlau werden, aber sie sind zumindest hilfreicher als so manche Meldungen der Betriebssysteme (z.B. MagiC: "68000 Exception").
Aus Alt wird Neu
Neben dem "Aufpolieren" der eigenen Programme kann man auch versuchen, ältere GFA-Programme, denen der Source beiliegt, neu zu kompilieren. Es kann durchaus sein, daß alleine dadurch schon viele Atari-User Gefallen am Milan fin-deen werden. Ist das Programm jedoch stark auf die nun nicht mehr funktionsfähigen Line-A-Befehle angewiesen, wird auch Licom nicht viel ändern können.
Zusammenarbeit mit faceValue
Beim ersten Versuch der Compilierung eines faceValue-Programms brach der Linker mit einer Fehlermeldung ab. Der Fehler im Programm lag in dem Befehl RESERVE. Dieser liegt zwar innerhalb einer IF...ENDIF-Konstruktion, die nur ausgeführt wird, wenn das Programm im un-compilierten Zustand vorliegt, aber beim Compilieren wird erst einmal das ganze Programm übersetzt. Damit das Compilieren ohne Fehler verläuft, hat man zwei Möglichkeiten:
(1) die Zeilen vor dem Compilieren zu entfernen oder (2) den Präprozessor von Ergo pro benutzen. Die zweite Variante ist sich die praktischere, und zudem bietet Ergo pro noch zusätzliche Optimierungsmöglichkeiten, so daß zusammen mit Licom ein wirklich schlankes Programm entsteht.
Fazit
Licom ist eine (friedliche) Revolution für GFA-Programmierer. Zusammen mit faceValue und Ergo pro hat man eines der modernsten Entwicklungssysteme für den Atari und zudem die Gewißheit, daß die Programme auch weiter entwickelt werden. Richard-Gordon Faika hat eine hervorragende Arbeit geleistet, und er plant sogar noch weitere Optimierungen! Das, was bis jetzt vorliegt, ist schon fast ein neues GFA-Basic und motiviert geradezu, die eigenen Programme so schnell wie möglich aufzupeppen und mit der gepatchten Library zu compilieren. Als Dank verlangt RGF eine Erwähnung der Licom im Programm, was sicherlich nicht zuviel verlangt ist. Aus meiner Sicht eines der zehn Top-Programme dieses Jahres!
Bezugsquelle:
Richard Gordon Faika Richard Sorge Str.24 10249 Berlin http://www.atari-computer.de/rgfaika/index.htm
Mia Jaap