Modula-2 - Der vergessene Schatz

TDI bietet für den ST ein Modula-2 System und einen dazugehörigen Toolkit an. Damit steht eine der modernsten Programmiersprachen zur Verfügung. Die GEM-Programmierung wird dabei vollständig unterstützt.

Modula-2 ist die Weiterentwicklung von Pascal. Ihr geistiger Vater ist N. Wirth, der Schöpfer von Pascal. Es bietet zusätzliche Datentypen, verbesserte Konstrukte und Funktionen. Das Wichtigste ist aber das namengebende Modul-Konzept.

Bild 1: Der Desktop

Ein Modula-Programm besteht aus einem oder mehreren Modulen. Interne Module fassen einige Prozeduren und Datenobjekte zusammen, von denen „außerhalb“ des Moduls nur „exportierte“ bekannt sind. Dadurch kann man logische Einheiten auch sprachlich zusammenfassen. Weiterhin werden Fehler vermieden, da bestimmte globale Daten von außerhalb nicht beeinflußt werden können.

Externe Modula entsprechen in etwa Bibliotheken, wobei jedoch schärfere Typenprüfungen durchgeführt werden. Durch sie läßt sich ein Programm in mehrere Unterprogramme aufteilen, die über klar definierte Schnittstellen miteinander kommunizieren. Dies entspricht modernen Konzepten der Softwaretechnologie.

Weiterhin bietet Modula-2 Coroutinen, mit denen nebenläufige Prozesse (Multitasking) realisiert werden können.

TDI-Modula-2

Das erste, was bei dem System auffällt, ist der eigene Desktop (Bild 1). Will man ein Programm editieren, braucht man nur in die „Definition“- oder „Implementation“-Spalte zu klicken, und der Editor wird mit dem entsprechenden File geladen. Das Starten des Compilers (= Erzeugen eines Link-Files) geschieht in der „Link“-Spalte. Ist z. B. ein Link-File nicht mehr aktuell, weil der Source-Text editiert wurde, so wird das jeweilige Icon schattiert dargestellt. Man kann die erzeugten Programme auch über einen Eintrag im „File“-Menü starten. Der Desktop unterstützt ideal die Programmentwicklung.

Das zweite Auffällige ist ein neues Ac-cessory namens „Modula-2 Options“. Man kann damit bestimmte Optionen für Compiler, Linker etc. setzen. Und man kann vier Pfade angeben, in denen etwa nach externen Modulen gesucht wird. In Bild 2 wird z. B. erst auf D: gesucht, dann in D: LIB .

Der Editor

Der Modula Editor (Bild 2 und Bild 3) läuft vollständig unter GEM.

Er bietet alle nötigen Kommandos zur Programmeditierung. Besonders praktisch ist das „Auto Indent“, das Programmzeilen richtig einrückt.

Tabs gehen bis zum Anfang des nächsten Wortes in der darüberliegenden Zeile. Sie können aber auch fest eingestellt werden. Auch eine „Undelete“-bzw. „Undo“-Funktion ist vorhanden, die selbst mehrere gelöschte Zeilen wiederbringt.

Bild 2: Die Suchpfade (im Hintergrund der Editor)

Der Compiler erzeugt bei Fehlern ein Error-File. Die Fehler können mit F7 oder per Menü angesprungen werden. In der Info-Zeile erscheint dann die Klartext-Meldung über den Fehler.

Im Text kann man sich mit den Cursor-Tasten, der Maus und dem Rollbalken bewegen. Leider fehlen die Rollpfeile nach oben und unten. Beim Hoch- oder Runterbewegen geht der Editor nicht automatisch in die nächste Zeile, wenn diese kürzer als die momentane Cursorspalte ist. Er sucht die nächste Zeile, die lang genug ist. Man muß dann mit F8 den Cursor bewegen.

Bei Diskettenzugriffen ist der Editor arg langsam geraten. Alle diese kleinen Mängel stören leider das ansonsten gut durchdachte Konzept des Editors.

Der Compiler

Es handelt sich um einen 5-Pass-Compiler, der alle nötigen Typenprüfungen ausführt. Da er und die externen Module jeweils ca. 200 KByte belegen, ist eine RAM-Disk für ein SF354-System unerläßlich, ansonsten aus Geschwindigkeitsgründen geboten. Ideal läuft das System natürlich mit einer Festplatte.

Der Sprachumfang ist den neuesten Empfehlungen Wirths angepaßt. Zusätzlich sind große Mengen implementiert. Den Typ LONGREAL verarbeitet der Compiler noch nicht, es ist aber zu erwarten, daß die nächste Version dahingehend erweitert wird (momentan sind nur REALs vorhanden, mit 32 Bit; LONGREALSs hätten 64).

Der Compiler läuft mit einer angemessenen Geschwindigkeit ab. Dabei ist zu berücksichtigen, daß er ja bei jedem externen Modul auf die Diskette zugreifen muß und mit Overlays arbeitet.

Die erzeugten Link-Files sind kompakt, jedoch größer als z. B. bei C-Systemen.

Dies liegt daran, daß mehrere Aufrufe an das Laufzeitmodul eincompiliert werden. Dieses Laufzeitmodul enthält die Verwaltung der Coroutinen (jedes Modula-Hauptprogramm wird als Co-routine aufgefaßt) und eine Fehlerbehandlung.

Der Compiler ist also groß und nicht gerade blitzschnell, dafür aber zuverlässig, fehlerfrei und ausgereift.

Der Linker

Der Linker packt das Hauptprogramm und alle importierten externen Module zusammen. Dies geht sehr schnell.

Über eine Optimierungsoption werden alle nicht benutzten externen Routinen entfernt. Die Größe der erzeugten Programme wird dann annehmbar, jedoch sind die Programme sicher immer größer als entsprechende C-Programme. Dies liegt aber wie schon bemerkt auch an der größeren Laufzeitumgebung (C bietet ja keine Coroutinen).

Der Linker arbeitet also auch zufriedenstellend. Compiler und Linker arbeiten natürlich unter GEM und geben Informationen in einem Fenster aus.

Die Bibliotheks-Module

Der Umfang und die Qualität der externen Module machen entscheidend die Güte eines Modula-Systems aus. Hier kann TDI-Modula-2 voll überzeugen.

Es stehen insgesamt 40 Module zur Verfügung. Sie teilen sich auf in die Standardmodule und GEM-Module.

Die Standardmodule enthalten alles Benötigte von Ein- und Ausgaben über String- und Mathmodule und Umwandlungen zwischen den verschiedenen Datentypen (z. B. Cardinais nach String) bis zu einem Filesystem-Modul. Die Module orientieren sich an den Vorschlägen von N. Wirth in „Programming in Modula-2“.

Die GEM-Module enthalten alle AES-Manager und die VDI-Funktionsgrup-pen. „GEMAESbase“ enthält auch eine Menge an vielbenötigten Konstanten oder Typen, so z. B. Message-Werte oder Object-Typen.

Schließlich sind auch noch BIOS-, XBIOS- und GEMDOS-Module vorhanden, mit denen man alle systemnahen Funktionen aufrufen kann.

Bild 3: Die Drop-Down-Menüs des Editors

Die mitgelieferten Module sind für alle Zwecke ausreichend und machen TDI-Modula zu einem vollständigen System (bei einem Modula-System für die IBM-PCs muß man übrigens solche Modula extra dazukaufen).

Das Handbuch

Das beiliegende „User’s Manual“ umfaßt 370 sauber gedruckte Seiten mit praktischer Ringbindung, allerdings in englischer Sprache. Alle Programme werden ausführlich beschrieben.

Näher eingegangen wird auf die Stan-dardmodule; bei den GEM-Modulen stehen einem nur Kommentare in den Definitionsmodulen zur Verfügung.

Neben Kapiteln über die Entwicklung von Accessories und Fehlerbeseitigung wird der Aufbau der Symbol- und Linkfiles genauestens beschrieben. Ein Abschnitt erläutert genau die Trap- und Registerbenutzung des Systems.

Den größten Teil nehmen dann die Auflistungen der Definitionsmodulen aller Bibliotheken ein. Ein Register gibt an, welche Bezeichner in welchen Modulen verwendet werden, und welchen Typ sie haben. Leider fehlen hier Hinweise auf die Seiten.

Ein letztes Kapitel geht kurz auf den Toolkit zum Modula-2 System ein.

Der Toolkit

Zu dem Modula-2 System ist ein passender Toolkit erhältlich. Er besteht aus vier Teilen: einem Debugger, einer GEM-Module, einem Resource-Editor, und einigen Utilities für Modula-2 Programme.

Der Debugger

Bei dem Entwanzer handelt es sich um einen sogenannten „Post-Mortem-Debugger“. Das bedeutet, daß der Debugger erst nach dem Absturz eines Programmes benutzt wird. Dies hat den Vorteil, daß Programme nicht durch den Debugger verlangsamt oder behindert werden. Dafür kann man allerdings nicht die Ausführung direkt verfolgen.

Damit der Debugger arbeiten kann, benötigt er einen Dump des Arbeitsspeichers bei der Fehlersituation. Das Laufzeitsystem erstellt diesen automatisch. Zusätzlich benötigt er noch einige Files, die der Compiler und der Linker auf Wunsch erzeugen.

Bild 4: Der Debugger bei der Arbeit

Der Debugger baut dann einen Bildschirm wie in Bild 4 auf. Man hat vier Fenster zur Verfügung. Das erste ist das „Process Window“. Hier findet sich eine Aufrufkette des Programms.

Im „Text Window“ hat man gleichzeitig den Sourcetext des Programms zur Verfügung, „rec“ ist eine rekursive Prozedur, die beim Aufruf mit 1 einfach ein „HALT“ ausführt, was einen Laufzeitfehler erzwingt.

Das „Data Window“ zeigt die Variablen, ihren Wert und Typ an. Man hat hier auch noch die Möglichkeit, z. B. Records extra aufspalten zu lassen oder lokale Daten zu überprüfen. Im „Memory Window“ findet sich ein Speicherauszug, der in verschiedenen Datentypen (Integer, Cardinal, Real etc.) angezeigt werden kann.

Leider ist das Programm noch nicht völlig fehlerfrei. So hängt sich der Debugger in einer bestimmten (provozierten) Situation auf. Sicher ist dies aber behebbar. Man hat mit dem Debugger auf jeden Fall äußerst viele Möglichkeiten, einem unerklärlichen Laufzeitfehler auf die Schliche zu kommen.

High-Level GEM Module

Es werden neun Module zur Verfügung gestellt, mit denen sich GEM-Programme einfach programmieren lassen. Die Module orientieren sich an den von N. Wirth in „Programming in Modula-2“ vorgestellten Routinen für Fenstertechnik und Grafik.

Interessant ist z. B. das „TextWindows“-Modul. Die Routinen bieten einem die Möglichkeit, ein Fenster zu öffnen und in diesem wie unter TOS Text auszugeben. Das Besondere dabei ist, daß auch die VT-52 Steuerzeichen beachtet werden. Man hat also die Emulation im Fenster.

Weitere Module dienen zum einfachen allgemeinen Windowhandling und zur Grafikausgabe in Fenstern. Hierbei sind auch Turtle-Graphics implementiert.

Der „EventDispatcher“ verarbeitet die AES-Events. Man kann durch einen einfachen Prozeduraufruf Routinen installieren, die z. B. einen Timer-Event verarbeiten. Der „EventDispatcher“ übernimmt selbständig den Aufruf, wenn ein Event vorkommt.

Die Prozeduren laufen sicher etwas langsamer ab, als speziell programmierte Programmteile. Dies kann man aber in Kauf nehmen, da man nicht immer wieder das Rad neu erfinden muß. Für viele läßt sich mit diesen Modulen auch die letzte Hürde für eigene Programme nehmen, die die GEM-Programmierung oft darstellt.

Bild 5: Der Icon-Editor im Resource-Editor

Der Resource-Editor

Bei dem Resource-Editor „MMRCP“ handelt es sich um eine lizensierte Version des gleichnamigen Programms aus dem Megamax-C System. Der einzige Unterschied besteht darin, daß keine C-Includefiles erzeugt werden können.

Ansonsten übertrifft das Programm den Editor aus dem Entwicklungspaket (der ja auch ab und zu abstürzt). Es bietet alle bekannten Funktionen zum Erstellen von RSC-Files. Zusätzlich ist ein Icon-Editor eingebaut (Bild 5), so daß eine Resource an einem Stück entwickelt werden kann.

Um Resources direkt im Modula-Programm einzubinden und somit das ".RSC“-File einzusparen, ist ein extra Utility vorhanden. Es erzeugt ein Modula-Programm, in dem die Resource per „CODE“-Befehl mitcompiliert wird.

Die Modula-Utilities

Die drei mitgelieferten Modula-Utilities dienen zum Analysieren von Modulen. „DECLNK“ liefert jede erdenkliche Information zu ".LNK"-Files. Unter anderem werden Disassemblings der enthaltenen Routinen und Konstanten geliefert. Bild 6 zeigt ein Beispiel für das Standardmodul „INOUT“.

„DECSYM“ analysiert ein ".SYM“-File und liefert als Ausgabe ein Definitons-Modul. Bild 7 zeigt wieder einen Ausschnitt für „INOUT“. Mit diesen beiden Utilities kann man leicht fremde Module unter die Lupe nehmen oder erzeugten Code analysieren.

Schließlich ist noch ein Cross-Reference Programm für Modula-Programme enthalten. Man erhält eine Liste sämtlicher Namen, Bezeichner und Angaben darüber, in welchen Zeilen des Programms sie enthalten sind.

Bild 6: Die Ausgabe von „DECLNK“

Dokumentation

Die Dokumentation zum Toolkit ist leider ziemlich dürftig. Vor allem die High-Level Module sind nur durch die ".DEF“-Files und ein Beispielprogramm dokumentiert. TDI sollte versuchen, ein Handbuch zu liefern, in dem nähere Informationen zu finden sind. Zum „MMRCP“ lag eine Beschreibung direkt von Megamax bei.

(* Syntax Version - 4H *)
(* ModuleKey = AC75H 4B2H 71H *)
DEFINITION MODULE InOut;
(* ModuleKey = AC75H 4B2H 71H *)
MODULE InOut;
IMPORT SYSTEM;
CONST
	EOL = DH(*CHAR*);
VAR
	Done (* RelAddr: OH *) : BOOLEAN;
VAR
	termCH (* RelAddr: 1H *) : CHAR;

PROCEDURE OpenInput(* ProcNum:1 *)(VAR ARRAY CHAR); 
PROCEDURE OpenInputFi1e(* ProcNum:2 *)(VAR ARRAY CHAR);

	END InOut; 
END InOut.

Bild 7: Die Ausgabe von „DECSYM“

Fazit

Das Modula System, das geradezu ideal in GEM eingebunden ist, bietet eine echte Alternative z. B. zum Megamax-C. Das Konzept von Modula eignet sich hervorragend auch für größere Projekte und ist die moderne Sprache der Zukunft.

Der Toolkit ist eine Sammlung nützlicher Utilities und Module, die speziell auf TDI-Modula und GEM zugeschnitten sind. Mit den High-Level Modulen wird die Programmierung von „echten“ GEM-Programmen entschieden erleichtert.

Der Support durch TDI bei Problemen ist übrigens hervorragend. Der Autor erhielt bei mehreren Anfragen prompt eine Antwort. Dabei wurde sogar eine Diskette mit Beispielprogrammen geschickt und ein Programm auf Diskette korrigiert!

Verbesserungen sind dringend beim Editor und beim Debugger nötig.

Auch kann der erzeugte Code noch optimiert werden. Der „MMRCP“ sollte zum Lieferumfang des Modula Systems ohne Aufpreis gehören, da ein solches Programm bei GEM-Program-mierung unbedingt notwendig ist.

Die Sprache kostet auf zwei Disketten DM 349,50 und der Toolkit (eine Diskette) DM 195. Bei direkter Bestellung bei TDI in England spart man etwas (der Toolkit kostet dort umgerechnet ca. DM 170).


R. Tolksdorf
Aus: ST-Computer 11 / 1986, Seite 28

Links

Copyright-Bestimmungen: siehe Über diese Seite