FTL-Modula - Die Feile, bitte!
Das in Großbritannien schon geraume Zeit auf dem Markt befindliche FTL-Modula von HiSoft ist nun auch hier im Vertrieb von CCD erhältlich. Das System kostet 299 DM und wird auf zwei doppelseitigen Disketten und mit einem Handbuch geliefert.
Installation
Vor der eigentlichen Installation müssen der Benutzername und die Seriennummer in die Systemprogramme eingetragen werden. Dazu dient das Programm INSTALL, in dem die nötigen Angaben getätigt werden. Damit hat CCD eine sinnvolle Lösung der Kopierschutzfrage gefunden, die auch bei ST-Pascal verwendet wird. Raubkopien lassen sich auf ihren Ursprung zurückführen, und wer nicht den korrekten Namen einträgt, ist von Updates ausgeschlossen. Dafür ist dann das komplette System frei von einem hinderlichen Kopierschutz. Das Testexemplar war von CCD übrigens schon vorinstalliert.
Die tatsächliche Installation beschränkt sich bei Systemen mit Festplatte auf das Kopieren sämtlicher Dateien der Systemdisketten in einen Ordner. Für die diversen Kombinationen aus Laufwerkskapazitäten und Speichergröße bietet das Handbuch verschiedenen Installationen an. Dabei werden hochformatierte Disketten und eine RAM-Disk verwendet. Nur die letzten Besitzer von einseitigen Diskettenlaufwerken müssen zunächst die Systemdisks bei CCD umtauschen.
Damit das System arbeiten kann, muss der Benutzer noch diverse Suchpfade und Systemoptionen über Environment-Variablen einstellen. Unter GEMDOS gibt es aber einige Probleme mit solchen Variablen, insbesondere lassen sie sich nicht in einem Profile oder einem AUTOEXEC.BAT setzen. Das Desktop bietet sie überhaupt nicht an, obwohl sie intern durchaus vorgesehen sind. FTL beinhaltet daher ein kleines Programm -ENVIRON.PRG -, das in den AUTO-Ordner kopiert wird. In einer zweiten Datei -ENVIRON.DAT - stehen die Inhalte der Variablen, die dann beim Booten automatisch gesetzt werden. Die Erzeugung von ENVIRON.DAT übernimmt der Batcher (s.u.).
Die Installation auf einer Festplatte belegt über 100 Dateien, für die ca. ein halbes Megabyte Plattenplatz nötig ist. Die Installation ist einfach und sollte aufgrund der genauen Beschreibung ün Handbuch keinerlei Probleme aufwerfen.
Oberfläche
Als Oberfläche bietet FTL keine der aufwendigen Grafik-Shells wie beispielsweise Megamax oder SPC. Vielmehr dient eine sehr einfache Shell, der "BATCHER", zur Steuerung. Dabei handelt es sich um einen Command-Line-Interpreter, der an das COMMAND von MS-DOS angelehnt programmiert wurde - und dementsprechend wenig bietet. Zur Dateipflege dienen die bekannten Operationen wie COPY, DEL, CD oder DIR.
Die schon angesprochenen Environment-Variablen verändert das SET-Kommando. Mit SAVE werden sie in die ENVIRON.DAT-Datei geschrieben und sind damit für das nächste Booten gerettet.
Etwas Komfort - beispielsweise gegenüber COMMAND.TOS von ATARI - bietet der Batcher bezüglich GEM-Programmen. Bei jedem gestarteten Programm mit der Endung PRG wird automatisch der Mauszeiger eingeschaltet, so dass keine Probleme bei Programmen mit grafischen Oberflächen entstehen.
Mag sein, dass die Arbeit mit einem Entwicklungssystem auf Shell-Basis vielen Programmierern entgegenkommt, deren persönlicher Arbeitsweise der Umgang mit der Maus etwas im Wege steht. Bei FTL allerdings ist die Shell zu einfach geraten, als dass sie wirklich einen Vorteil gegenüber den fulminanten Konkurrenzprodukten bietet. Es erscheint angeraten -und auch möglich -, den Batcher durch die Public Domain-Shell Guläm zu ersetzen. Neben der vorhandenen Alternative, die Systemprogramme vom Editor aufrufen zu können, ist eine einfache GEM-Shell in Vorbereitung. Die Arbeitsschritte werden dann mit Maus und Menüs unterstützt.
Editor
Der GEM-gestützte Editor kann bis zu fünf Fenster verwalten und wird mit einer Mischung aus Tastatur- und Menükommandos (Bild 1) bedient. Die Tastatursteuerung lehnt sich stark an den Control-Tastenlastigen Wordstar an, dessen Tastenbelegung auch heute noch in vielen Borland-Produkten zu finden ist. Für viele Befehle gibt es eine doppelte Belegung mit Alternate oder den Funktionstasten.
Vorhanden sind die üblichen Editor-Features mit Cursor-Bewegungen, Löschen, Suchen und Ersetzen sowie Blockbefehlen. Leider können Blöcke nicht mit der Maus markiert werden, zudem wird ein gesetzter Block nicht auf dem Bildschirm markiert.
Bis zu zehn Marken lassen sich setzen und anspringen. Findet der Compiler einen Fehler, kann weiter compiliert und die Fehlerposition in einer Marke vermerkt werden. Die Beschränkung auf nur zehn Marken und damit Fehler ist doch sehr knapp bemessen.
Als einer der wenigen Editoren verwendet das Programm wirkliche Tabulatoren. Die Einrückungstiefe per Tabulator läßt sich im Menü Tabs einstellen. Ebenfalls dort findet sich die Option AutoTab zum automatischen Einrücken neuer Zeilen. Völlig unlogisch ist allerdings, dass eine Änderung der Tabulatorenweite das Auto-Indent jedesmal abschaltet.
Ein weiteres interessantes Feature ist die Möglichkeit, dieselbe Datei in zwei Fenstern darzustellen. Somit könnte man in einem Fenster eine Reihe Variablendeklarationen anzeigen und auf dem Bildschirm zur Erinnerung bereithalten, während in einem anderen Fenster eine Prozedur desselben Programms ausgearbeitet wird.
Für wiederkehrende Befehlsfolgen ist ein Makrorekorder implementiert. Nach <ESC›,<Control›+L kommt man in einem Lernmodus, der sämtliche Aktionen mitschreibt und nach einem erneuten <ESC›,<Control›+L bereitstellt. Die Makros werden durch beliebige Zeichenketten bezeichnet, die beim Schreiben automatisch gesetzt werden. Verwendet man aber längere Namen, hat das zur Folge, dass der Editor die Eingabe verzögert übernimmt, da sie erst mit den bekannten Makro-Namen verglichen wird. Vielleicht sollte ein Makro-Aufruf doch durch einen Befehl eingeleitet werden, wenn der Name mehrere Zeichen umfaßt.
Durch die Makros wird es möglich, die komplette Tastenbelegung des Editors umzudefinieren. In der Auslieferung befinden sich drei Belegungsdefinitionen, die jeweils mit Makro laden eingestellt werden können. Diese Bindings werden in Klartext definiert; eine konkrete Anleitung dazu findet sich aber nur in den -durchaus gut kommentierten - mitgelieferten Dateien.
Der Editor hat leider einige Probleme mit GEM. Die Reaktionszeit auf Slider-Bewegungen ist ungewohnt hoch. Die Größe der Fenster wird bei Bewegungen automatisch an die Bildschirmränder angepaßt. Es ist also nicht möglich, ein Fenster aus dem Bildschirm teilweise herauszuschieben. Die Folge wird eine größere Zahl von Sizer-Operationen durch den Benutzer sein.
Der Compiler läßt sich im Menü Ausführen mit und ohne Code-Erzeugung starten; ebenso der Linker. Der Menüpunkt Programm führt ein beliebiges Programm aus, womit alle anderen System-und Hilfsprogramme bereitstehen. Die Shell kann mit Batcher gestartet werden. Compiler Flags im Menü Optionen erlaubt das Anwählen der Compiler-Optionen. Seltsamerweise fehlt ein entsprechendes Kommando für den Linker.
Neben leichten Problemen mit GEM müßte der Editor überarbeitet werden, soll er zugleich die Entwicklungsoberfläche integrieren. So müssen noch einige Feinheiten bereinigt und etwas mehr Komfort geboten werden. Der Editor hat also noch etwas Überarbeitung nötig. Solange sollte die Verwendung eines anderen Editors problemlos sein, besondere Probleme bei der Einbindung beispielsweise von TEMPUS dürften nicht entstehen.
Compiler
Der FTL-Compiler erweitert Modula-2 an einigen Stellen. So dürfen in Bezeichnern beispielsweise auch die Zeichen "$" und " " vorkommen.
Teilweise implementiert ist die Möglichkeit - ähnlich wie in C -, Variablen bei ihrer Deklaration einen Initialwert zuzuweisen. Zeichenkonstanten können neben der üblichen oktalen Darstellung auch im hexadezimalen Zahlensystem notiert werden. Opaque Type müssen nicht mehr unbedingt vom Typ POINTER sein. Dazu ändert der Compiler beim Übersetzen des Implementationsmoduls nachträglich die .SYM-Datei.
Prozedurkonstanten lassen Zeilen wie "CONST Schreibe = WriteString" zu. Im Programm wird dann Schreibe jeweils ersetzt, und zur Verwendung einer anderen Ausgabeprozedur muss lediglich die Konstantendefinition geändert werden. Anstelle einer direkt geschachtelten WITH-Anweisung kann auch in einem WITH eine Liste von Record-Variablen stehen.
Ein weiterer Unterschied, den ich eher als Fehler bezeichnen möchte, ist das obligatorische BEGIN in einem Prozedurkörper. Eine Deklaration mit einem leeren Prozedurkörper PROCEDURE a; END a; ist nicht mehr möglich, es muss PROCEDURE a; BEGIN END a; lauten.
Jede Benutzung dieser Erweiterungen macht die Programme natürlich nicht mehr portabel. Ob sie bei dieser Einschränkung allerdings noch Vorteile bringen, ist fraglich. Es gibt eigentlich keinen Grund, das Dollar-Zeichen und den Unterstrich verwenden zu müssen, ebenso lassen sich die etwas unsichereren Prozedurkonstanten (keine Festlegung der Parameterstrukturen) auch über Prozedurvariablen realisieren. Auf jeden Fall aber wird FTL nicht sofort an den neuen Modula-Standard anzupassen sein, sollte dieser eines Tages tatsächlich verabschiedet werden.
Der Compiler wird entweder vom Editor oder aus dem Batcher unter Angabe des Quelltexts aufgerufen. Dabei können verschiedene Optionen gesetzt bzw. nach einem Schrägstrich an den Programmaufruf angehängt werden.
Die Optionen steuern das Verhalten des Compilers beim Übersetzen. Dabei können ein Bildschirm-Listing ausgegeben sowie Warnungen ausgeschaltet werden. Die Code-Erzeugung beeinflußt die bekannten Schalter zur Eincompilierung von Code zur Bereichsüberprüfung bei Feldzugriffen sowie der Erkennung von Overflow-Fehlern. Diverse weitere Schalter steuern die Erzeugung von Zusatzinformationen für das Debugging.
Mit den bekannten Pseudokommentaren können die Einstellungen auch selektiv für bestimmte Bereiche des Programmtextes ein- und ausgeschaltet werden.
Hier kommt eine weitere Option hinzu, die nicht beim Compiler-Aufruf gesetzt werden kann. In String-Konstanten lassen sich unter Verwendung eines Escapes auch nicht-druckbare Zeichen darstellen. So erzeugt beispielsweise "AL" ein Form-Feed (ASCII-Code 12). Mit ($A!) würde das voreingestellte Escape "A" auf das Ausrufezeichen umgestellt.
Benchmarks
In Bild 2 finden Sie die gewohnte Benchmark-Tabelle, in der FTL nun schon die achte Spalte füllt. Die ersten Ergebnisse (Benchmarks 2-5) zeigen, dass FTL der erste Compiler ist, der aus einem i:=i+l ein INC(i) optimiert.
Dagegen erreicht FTL bei den verschiedenen Kontrollkonstrukten (8-10,21-24) wie Schleifen oder Fallunterscheidungen nur mittelmäßige Werte. Hier scheint die Konkurrenz etwas besser auf den 68000 zu optimieren.
Da REAL mit 64 Bit implementiert ist, wurden die Zeiten den LONGREAL-Ergebnissen der Konkurrenten gegenübergestellt (Benchmark 26). Es zeigt sich, dass die Fließkomma-Arithmetik nicht optimal vorliegt, der Benchmark lieferte das schlechteste Ergebnis. Beim Test der Libraries (27a) schlägt dieser Wert erstaunlicherweise nicht zu stark durch, dennoch sind die höheren REAL-Funktionen ebenfalls nicht sonderlich schnell. Ein Blick in den Quellcode der MathLib zeigt, dass alle Aufrufe an weitere Module durchgereicht werden, und dort unoptimiert in Hochsprache formuliert sind.
Trotz der schnellen Feldzugriffe (29) konnte sich auch die String-Verarbeitung keinen Spitzenplatz erobern (28). Insgesamt scheint FTL Stärken in der Ganzzahl-Arithmetik zu haben, verfehlt bei den Kontrollkonstrukten aber deutlich die Zeiten der Konkurrenz. Die Bibliotheken sind nicht sonderlich optimiert, eine Aufgabe, die hoffentlich nicht auf die Benutzer abgewälzt bleibt.
Linker
Der Linker (Bild 3) bindet die vom Compiler oder Assembler (s.u.) erzeugten Link-Dateien zu einem GEMDOS-Programm zusammen. Über einen Schalter lassen sich auch Accessories erzeugen.
RT Modula-2 Benchmarks
| Nr. | TDI V3.0 | Jefferson | Megamax | Softwave | SPC V1.41 | LPR | MAMOS V1.3 | FTL | test... |
| 1 | 0:07 | 0:07 | 0:07 | 0:04 | 0:05 | 0:05 | 0:02 | 0:04 | Prozeduraufruf |
| 2 | 1:42 | 1:33 | 2:59 | 1:35 | 1:31 | 1:31 | 1:27 | 1:17 | Addition |
| 3 | 1:21 | 1:18 | 1:58 | 1:20 | 1:16 | 1:16 | 1:12 | 1:17 | Increment |
| 4 | 1:47 | 1:38 | 2:59 | 1:40 | 1:36 | 1:36 | 1:32 | 1:22 | Additionsoptimierung |
| 5 | 1:27 | 1:23 | 2:08 | 1:25 | 1:21 | 1:22 | 1:17 | 1:22 | Increment als Vergleich |
| 6 | 2:09 | 1:57 | 3:48 | 2:01 | 1:55 | 1:55 | 1:51 | 1:37 | INTEGER-Addition |
| 7 | 2:09 | 1:57 | 3:48 | 2:01 | 1:55 | 1:55 | 1:51 | 1:37 | CARDINAL-Addition |
| 8 | 1:11 | 1:18 | 1:42 | 1:05 | 1:15 | 1:16 | 1:12 | 1:22 | FOR-Schleife |
| 9 | 1:21 | 1:02 | 1:42 | 1:05 | 1:00 | 1:00 | 0:56 | 1:02 | REPEAT-Schleife |
| 10 | 1:21 | 1:18 | 1:57 | 1:20 | 1:15 | 1:15 | 1:12 | 1:17 | WHILE-Schleife |
| 11 | 1:04 | 0:54 | 1:15 | 0:38 | 0:51 | 0:53 | 0:48 | 0:45 | INTEGER-Parameter |
| 12 | 1:04 | 0:54 | 1:17 | 0:38 | 0:51 | 0:53 | 0:48 | 0:44 | INTEGER VAR-Parameter |
| 13 | 1:06 | 0:59 | 2:19 | 0:33 | 0:57 | 0:57 | 0:53 | 0:58 | RECORD-Parameter |
| 14 | 0:34 | 0:30 | 0:41 | 0:20 | 0:28 | 0:28 | 0:24 | 0:25 | RECORD VAR-Parameter |
| 15 | 0:49 | 0:49 | 1:33 | 0:42 | 0:46 | 0:47 | 0:43 | 0:44 | Konstanten- Optimierung |
| 16 | 0:51 | 0:51 | 1:33 | 0:44 | 0:49 | 0:49 | 0:45 | 0:52 | Konstanten- Optimierung |
| 17 | 1:28 | 1:26 | 2:06 | 1:19 | 1:23 | 1:24 | 1:20 | 1:28 | Expression- Optimierung |
| 18 | 1:42 | 1:22 | 1:59 | 1:15 | 1:19 | 1:20 | 1:16 | 1:23 | Expression-Optimierung |
| 19 | 0:37 | 0:36 | 0:55 | 0:30 | 0:33 | 0:34 | 0:29 | 0:33 | Zwischenergebnis-Optimierung |
| 20 | 0:37 | 0:35 | 0:55 | 0:30 | 0:33 | 0:34 | 0:29 | 0:33 | Zwischenergebnis-Optimierung |
| 21 | 0:09 | 0:11 | 0:13 | 0:09 | 0:08 | 0:09 | 0:05 | 0:10 | IF-Statement |
| 22 | 0:13 | 0:13 | 0:16 | 0:11 | 0:11 | 0:12 | 0:07 | 0:12 | IF durch GASE ausgedrückt |
| 23 | 0:38 | 0:33 | 0:41 | 0:28 | 0:30 | 0:31 | 0:27 | 0:38 | CASE-Statement |
| 24 | 0:40 | 0:39 | 1:03 | 0:38 | 0:36 | 0:36 | 0:33 | 0:37 | GASE durch IF ausgedrückt |
| 25 | 0:47 | 1:03 | ? | 2:09 | 0:49 | 0:48 | 0:42 | ? | REAL- Arithmetik |
| 26 | 2:05 | ? | 1:32 | 2:18 | 2:07 | 2:00 | 1:58 | 2:37 | LONGREAL- Arithmetik |
| 27 | 1:52 | 5:42 | ? | ? | 3:51 | 3:16 | ? | ? | REAL-Library |
| 27a | 5:39 | ? | 2:35 | 35:40 | 3:30 | ? | 16:13 | 6:28 | LONGREAL-Library |
| 28 | 1:21 | 1:21 | 0:40 | 0:30 | 0:51 | ? | 2:20 | 1:28 | String-Library |
| 29 | 2:10 | 2:07 | 2:13 | 1:48 | 1:44 | 2:04 | 2:01 | 1:33 | ARRAY- Zugriffe |
| 30 | 0:09 | 0:10 | 0:17 | 0:19 | 0:08 | 0:08 | 0:04 | 0:12 | RECORD-Zugriffe |
| Alle Zeiten mit time-Kommando von Guläm gemessen MAMOS 1.3 mit 200Hz-Zähler gemessen Meßgenauigkeit bis zu ±0.5 Sekunden Angabe "'-'": Sinnlos bzw. keine Bibliotheken |
|||||||||
Zur Optimierung des gebundenen Programms, also der Entfernung aller nicht benötigten Routinen, ist ein etwas umständliches Procedere nötig. Zunächst muss ein Link-Vorgang durchgeführt werden, der über ein Flag eine Datei mit Informationen über die Prozeduraufrufe erzeugt. Diese wird durch ein weiteres Programm - den TRIMMER - geschickt, der wiederum eine Informationsdatei für den Linker erzeugt, die beschreibt, an welchen Stellen Code herausgelassen werden kann. Der Linker verarbeitet diese dann in einem zweiten Link-Vorgang und erzeugt endlich ein kompakteres Programm. Die Konkurrenz zeigt dass diese Arbeitsschritte - die allerdings nur für die endgültige Programmversion nötig sind -auch direkt im Linker integrierbar sind und nicht etwa einen doppelten Linkeraufruf und die Verwendung eines weiteren Programm bedingen.
Weitere Flags steuern Stack-Überprüfung und -große und können die vom Compiler erzeugte Bereichsprüfung wieder rückgängig machen. Wie beim Compiler gibt es auch hier einige Flags, die das
Programm durch Zusatzinformationen zum Debuggen vorbereiten. Schließlich läßt sich auch ein Mathe-Coprozessor durch Einbinden entsprechender Module ansteuern.
Bibliotheken
Die externen Module liegen bei FTL-Modula in Sammelbibliotheken vor. Eine solche Bibliothek hat ein eigenes Inhaltsverzeichnis und faßt die vielen sonst üblichen kleinen Einzeldateien in einer großen zusammen. Die Dateien können dabei mit zwei verschiedenen Komprimierungsarten gepackt werden. Zur Verwaltung steht ein Bibliotheksmanager bereit, der weiter unten besprochen wird. Der Vorteil des Verfahrens liegt auf der Hand. Anstelle von hunderten von Einzeldateien wird nur noch mit wenigen Sammelbibliotheken gearbeitet. Vorrangig spart dieses Verfahren Platz und ist eventuell auch schneller, da nicht mehr immer ein GEMDOS-Open durchgeführt werden muss. Eine zusätzliche Bibliothek enthält übrigens den Quellcode sehr vieler mitgelieferter Module.
Die Modula-Standardmodule wie Storage oder Strings sind vorhanden. Die Ein- und Ausgabe wird neben InOut abgestuft angeboten. Dabei existiert ein "höheres" Modul - ScreenIO -, das Textfenster mit Attributen verwalten kann. Die Strukturierung der Bibliotheken lehnt sich wenig an den empfohlenen Standard an, so heißt MathLibO bei FTL Maths,
An vielen Stellen zeigt sich der Ursprung der Bibliotheken aus MS-DOS. So sind einige Module zur Interrupt-Verwaltung vorhanden; ein Bereich, der auf dem PC ungleich wichtiger ist.
An Besonderheiten gibt es beispielsweise eine Bibliothek zum Lösen von Gleichungssystemen oder einen Quicksort. Ein paar sehr systemnahe Module erlauben das schnelle Verschieben von Speicherblöcken und Bit-Manipulationen.
ATARI- bzw. GEM-spezifische Module sind im üblichen Umfang vorhanden. Dies reicht von BIOS, XBIOS, GEMDOS und der Line-A bis zu den gewohnten AES- und VDI-Bibliotheken. Die Bezeichner bei letzteren entsprechen in etwa den Vorlagen aus dem C-Entwicklungspaket von ATARI. Damit sind sie kryptisch, schlecht zu lesen und zu merken und nutzen Modula nicht aus. Höhere Module für die GEM-Benutzung sind nicht in dem Umfang wie bei der Konkurrenz zu finden.
Die Beurteilung der Bibliotheken ist schwierig. Eigentlich ist alles vorhanden, was man auf dem ST braucht. Im Vergleich mit der Konkurrenz aber fehlen die aufwendigen Komfort-Module für GEM, und es gibt eigentlich keine Stelle, an der die FTL-Module Besonderes bieten.
Assembler
Dem Paket liegt ein 68000-Assembler mit Schnittstelle zum Modula-System bei. Die Autoren begründen dies damit, dass einige der mitgelieferten Bibliotheksquellen in Assembler vorliegen, und weisen ausdrücklich daraufhin, dass das Programm keine vollständige Assembler-Umgebung bietet. Die Aussage im Handbuch, "Außerdem waren wir beim Testen des Assemblers ... nicht so gründlich wie bei den anderen Komponenten des Systems - er arbeitet jedoch zufriedenstellend", klingt wie eine Entschuldigung und verunsichert den Anwender.
Der Assembler-Text wird mit Motorola-Mnemonics in der üblichen Notation geschrieben. Vordefiniert sind Bezeichner für die Register und einige Operatoren für Ausdrücke. Die Assembler-Pseudoanweisungen beinhalten das Nötigste, wie DB, DW, DW, EVEN oder EQU. SET kann mit veränderlichen Marken arbeiten.
Ein Assembler-Modul besteht aus einem in Modula geschriebenen Definitionsmodul und einem Assembler-Text, der praktisch das Implementationsmodul darstellt. Der Assembler erzeugt daraus ein Linkmodul wie der Compiler.
Der Assembler bietet eine Schnittstelle, mit der Bezeichner im- und exportiert werden können. Dabei finden allerdings keine Typüberprüfungen statt, womit bei den ersten Versuchen wahrscheinlich einige schwer zu findende Fehler auftreten.
Eine Pseudo-Anweisung - IMPORT -gefolgt von einem Modulnamen und einer Namensliste importiert Bezeichner aus externen Modulen. Die Anweisung LABEL gibt einen Bezeichner nach außen bekannt und wird somit jede in Assembler definierte Prozedur einleiten.
Das Handbuch beschreibt die einfache Prozeduraufruf-Konvention. Daraus ein Beispiel zur Ausgabe eines Textes auf dem Bildschirm:
IMPORT Terminal, WriteString, WriteLn ISECT Hi: DBHiThere.O CSECT MAIN PEA Hi MOVE.L #8,-(A7) MOVE.L #7,-(A7) JSR WriteString JSR WriteLn RTS END
Nach dem Import von WriteString und WriteLn aus Terminal folgt ein Datenbereich, der den auszugebenden String definiert. Die Vorbereitung des Aufrufs von WriteString besteht aus dem Ablegen der String-Adresse, der Anzahl der belegten Bytes und der oberen Feldgrenze. Die letzten beiden Werte sind nötig, da WriteString ein offenes Feld als Parameter erwartet. Der tatsächliche Aufruf von WriteString geschieht über ein simples JSR.
Assembler wird von den Autoren nur zur Geschwindigkeitsoptimierung empfohlen. Größere Programme in Assembler zu entwickeln wird wahrscheinlich auch an dem mangelnden Komfort scheitern. Gerade Prozeduraufrufe könnten Makros erheblich vereinfachen.
Der Assembler ist also eher ein Hilfsprogramm für letzte Optimierungen, das aber bei der normalen Programmentwicklung eine eher untergeordnete Rolle spielen wird. Gegenüber anderen Lösungen mit Inline-Assembler paßt sich die Erzeugung von Implementations-Modulen durch den separaten Assembler besser in das Modula-Konzept ein.
Debugger
Zum Debuggen existiert ein symbolischer Debugger, der Einzelschrittverarbeitung auf Anweisungsniveau, Variablen-Monitoring und Break-Punkte bietet.
Das Programm - das auch nicht auflösungsunabhängig ist - meldet sich auf einem eigenen Bildschirm mit einem eigenen Menü (Bild 4). Nachdem ein Modul zur Abarbeitung geöffnet ist (dies ist normalerweise das Hauptmodul), lassen sich einige Einstellungen zum Entwanzen vornehmen.
"Var anzeigen" nimmt eine (per Menü ausgewählte) Variable in die ständige Anzeige auf. Will man nur kurz über den momentanen Wert einer Variablen informiert sein, wird er mit "Var untersuchen" temporär dargestellt. Für die Darstellung gibt es verschiedene Optionen, so kann beispielsweise ein Feld ab einem beliebigen Index angezeigt werden.
Jeweils eine Anweisung führt "Nächster Schritt" aus. Dabei sind aber nicht etwa 68000-Anweisungen, sondern Modula-Anweisungen gemeint. Die Schrittweite läßt sich ebenfalls einstellen, so dass man beispielsweise nur nach jeder dritten Anweisung wieder im Debugger landet. "Nächste Anweisung" führt das Programm bis zur nächsten Anweisung auf gleichem Niveau aus. Damit gelten ein Prozeduraufruf oder eine Schleife als eine Anweisung.
Break-Punkte lassen sich ebenfalls durch Angabe einer Zeilennummer setzen und löschen. "Ausführen" arbeitet das Programm danach solange ab, bis es auf einem Break-Punkt stoppt oder ein Laufzeitfehler auftritt. Alle Ausgaben eines Programms gehen auf einen anderen Bildschirm, der sich mit "PRO Bildschirm" anzeigen läßt.
"Zeit-Modul" fertigt ein Zeitprofil des Programmablaufs an. In einer dabei entstehenden Datei ist danach vermerkt, welche Anweisung wieviel Zeit des gesamten Programmlaufs beansprucht. Damit lassen sich sehr gut kritische Stellen im Programm aufspüren und Optimierungen zielgerichtet durchführen.
Die nicht direkt lesbare Datei mit dem Zeitprofil wird danach vom Programm PRTIME umgesetzt. Nach Auswahl in einer Dialogbox lassen sich die Laufzeiten (in Anteilen an der gesamten Programmdauer) auf dem Bildschirm (Bild 5) oder in einer externen Datei darstellen. Bei letzterem fehlen leider unverständlicherweise die Zeitangaben. Die Bildschirmdarstellung hat einige Schwächen bei der GEM-Benutzung.
Beim Austesten des Debuggers traten einige Ungereimtheiten auf. Bei einem gesetzten Break-Punkt wurde nur einmal gestoppt, obwohl er sich in einer Schleife befand. Das Zeitprofil konnte nicht befriedigen (Schleifen im Hauptteil eines Programms wurden nicht ausgemessen) und bei der Ausgabe in einer Datei wurden die Einrückungen plötzlich nicht mehr beachtet, bei einem Durchlauf brach die Darstellung willkürlich im Programm ab. Der Debugger bzw. das Zeitprofil scheinen noch fehlerhaft implementiert zu sein. Das Konzept ist zwar das richtige, aber durch die Fehler wird die Nutzbarkeit des Werkzeugs an vielen Stellen eingeschränkt.
Für andere Anwendungen läßt sich der Compiler über ein Flag zum Eineompilieren zusätzlicher TRAP-Befehle bewegen. Bindet man über den entsprechenden TR AP-Vektor einen eigenen Monitor ein, läßt sich der Programmverlauf überwachen. Ein solcher Monitor wird samt Quellcode mitgeliefert. Das Programm bleibt resident im Speicher und zeigt in der vorliegenden Form beispielsweise Prozeduraufrufe an.
Hilfsprogramme
Wie oben schon angesprochen, gibt es für die Verwaltung der Sammelbibliotheken ein gesondertes Programm, MLU. Ähnlich wie bei den bekannten Komprimierungsprogrammen ARC oder ZOO kann es in einer Bibliothek Manipulationen wie Hinzufügen, Löschen und Extrahieren von Dateien durchführen. Neben Inhalts-Listings und Verwaltungsfunktionen wie Reorganisation des Archivs und Updates eventuell veränderter Dateien bietet eine Hilfe-Funktion eine Übersicht über die Kommandos. MLU arbeitet interaktiv per Kommandobuchstaben (Bild 6). Damit ist die Oberfläche etwas spartanisch geraten, erfüllt aber ihren Zweck.
Für größere Programmierprojekte liegt ein Make-Programm bei, mit dem bei Programmänderungen automatisch die veränderten Dateien und alle von ihnen abhängigen neu compiliert werden.
Praktischerweise müssen die Abhängigkeiten zwischen Modulen nicht von Hand beschrieben werden. Dem Programm MCSCAN übergibt man einfach den Namen des Hauptmoduls, das auf Abhängigkeiten durchsucht wird, die automatisch in ein Makefile geschrieben werden.
Das Makefile kann per Hand ergänzt werden, was bei der Verwendung des Assemblers auch nötig ist. Das Make erstellt intern eine Stapeldatei für den Batcher und führt diese direkt aus, womit die Compiler-Aufrufe automatisiert sind. Bei Verwendung des Makes vom Desktop aus muss das Batchfile mit einem weiteren Hilfsprogramm gesondert erstellt werden. Die Datenfiles sind auf den mitgelieferten Batcher eingestellt und müssen für Guläm in Sachen Parameterübergabe angepaßt werden.
Für Module, die sich gegenseitig importieren, bieten die Programme PRECEDENCE und BUILDSUB eine Unterstützung beim Compilieren. Ersteres erzeugt eine Datei mit Informationen über die Abhängigkeiten zwischen den Modulen, BUILDSUB erstellt eine Batch-Datei, die den Compiler in der für die zyklischen Referenzen nötigen Reihenfolge für die Definitions- und Implementationsmodule automatisch startet. BUILDSUB scheint aber nicht richtig an das ST-System angepaßt worden zu sein: Die Batch-Datei enthält einen Aufruf "MD" - ein Programm, das nicht vorliegt. Unverständlicherweise müssen diese Programme noch aus dem vorliegenden Quellcode übersetzt werden, vielleicht sollten sie doch der Einfachheit halber lauffähig mitgeliefert werden.
Für die Erstellung von Resourcen liegt ein Resource-Construction-Set bei, und zwar WERCS, das mit FTL erstellt wurde. Das Programm entspricht in seinen Fähigkeiten den anderen bekannten Resource-Construction-Sets, ist aber an einigen Stellen nicht so komfortabel wie beispielsweise NRSC von Kuma. Zwar können Objekt mit der Maus verschoben oder verdoppelt werden, die Attribute muss man jedoch über die Drop-Down-Menüs (Bild 7) setzen.
Soll also das Füllmuster geändert werden, muss der Mauszeiger das Objekt anwählen, dann zum oberen Bildschirmrand und das Menü und den Eintrag auswählen. Eine Dialogbox, die auf Doppelklick auf das Objekt angezeigt wird, scheint doch komfortabler zu sein, wobei auch mehrere Attribute schnell zusammengesetzt werden können.
Neu für ein Resoürce-Construction-Set ist die Möglichkeit, die Ausgabedateien an die verwendete Programmiersprache anzupassen. Eine Textdatei legt fest, dass beispielsweise für C die Anweisung "#define" und in Modula "CONST" für Konstante verwendet werden soll. Vordefiniert sind C, Pascal, Modula, Fortran, Assembler und Basic.
Sonstiges
Für Benutzer, die über keine Festplatte verfügen, sind zwei Utilities gedacht. Da ist zunächst ein Formatierprogramm, das die Diskettenkapazität auf 400 bzw. 800 kByte erhöht. Dazu werden die Disketten mit 10 Sektoren formatiert.
HRAMDSK ist eine resetfeste RAM-Disk, die sich per AUTO-Ordhier installiert. Dabei können automatisch Dateien in die RAM-Disk kopiert werden, so dass das System dann zur Arbeit bereit ist. Zur Konfiguration der RAM-Disk gibt es ein eigenes Installationsprogramm, das in einer Dialogbox die Liste der zu ladenden Dateien, den Laufwerksbuchstaben und die Größe der RAM-Disk einstellt.
Handbuch
Das deutschsprachige Handbuch umfaßt fast 500 Seiten und wird in einem stabilen Ringordner geliefert. Es gliedert sich in drei Hauptteile, eine Sprachreferenz über die Modula-Implementierung, ein Benutzerhandbuch, das die Entwicklungsumgebung beschreibt, und eine gesonderte Anleitung zum Resource-Construction-Set WERCS.
Die Beschreibung ist immer wieder mit Beispielen illustriert, vielleicht sollte die Ausgabe einiger Hilfsprogramme dokumentiert werden. Die genaue Gliederung erlaubt das schnelle Auffinden der gewünschten Informationen. Es existieren zwei Register für das Modula-System und das WERCS, die an einigen Stellen etwas umfangreicher sein könnten.
Ein wirkliches Ärgernis - wie schon bei MAMOS-Modula - ist das Fehlen von Listings der Definitionsmodule. Zwar beschreiben cirka 100 Seiten des Handbuchs die Module, insbesondere bei den Standardmodulen findet man aber keine Angaben über die Parameterstrukturen. Auch sind exportierte Datentypen nicht dargestellt. Zum schnellen Nachschlagen ist dieser Teil nicht geeignet.
Es bleibt also nur das langwierige Ausdrucken aller Definitionsmodule. Heraus kommen über 100 Druckerseiten, die natürlich nicht in das DIN A5-Handbuch eingeheftet werden können und einen unordentlichen und unhandlichen Stapel bilden. Das mitgelieferte LIST-Programm führt übrigens keine vernünftige Paginierung durch, so dass das Ausdrucken nicht sonderlich unterstützt wird.
Das Argument, dass die Bibliotheken ständig erweitert werden, kann nicht gelten, immerhin liegt das Handbuch auch hier als Ringbuch vor. Ergänzungen sind so kein Problem; ein Verfahren, das bei SPC-Modula hervorragend funktioniert.
Das Handbuch ist also annehmbar und wird eigentlich alle Fragen beantworten. Ohne eine Ergänzung um die Listings der Definitionsmodule ist es aber für die tägliche Arbeit unvollständig.
Fazit
Der erste Eindruck des Pakets mit den vielen Hilfsprogrammen, der angebotenen Zeitprofil-Analyse und der kompakten Speicherung der externen Module ist positiv. Einige Konzepte weisen in die richtige Richtung, wären sie doch nur fehlerfrei implementiert. Bei genauer Betrachtung zeigt sich eine Reihe Mängel, die die Qualität des Pakets letztlich beeinträchtigen.
FTL-Modula deutet eine sinnvolle Ausstattung an, ist aber an vielen Stellen noch lange nicht ausgereift. Eine neue Version könnte interessant werden; hoffentlich nutzen die Entwickler die Zeit, denn momentan kann FTL noch nicht gegen die breite Modula-Konkurrenz bestehen.
RT