Computer-Magazin-Archiv
Über Vorzüge und Nachteile verschiedener Hochsprachen gibt es bekanntlicherweise immer wieder hitzige Diskussionen zwischen Programmierern. Die bekanntesten und am weitesten verbreiteten Sprachen sind Fortran, Pascal und vor allem C. Fortran wird hauptsächlich im technischwissenschaftlichen Bereich angewendet, Pascal für Anwendungen und C für Anwendungen und Betriebssysteme.
Relativ unbekannt ist Modula-2, die konsequente Weiterentwicklung von Pascal. Jeder hat zwar davon gehört und gibt einen Kommentar über die Sprache ab, die wenigsten jedoch kennen diese Sprache wirklich.
Es ist genauso wie der Streit zwischen DOS- und ATARI-Usern: die ATARI-User kennen DOS und können daher eine Aussage darüber treffen, was sie besser finden. Die wenigsten DOS-User jedoch kennen den ATARI und tun ihn als Spielkiste ab.
Handelte es sich bei Pascal noch um eine Lehrsprache, die von Nikiaus Wirth, dem Entwickler beider Sprachen, primär für Schulungszwecke entworfen wurde, so ist Modula-2 die Sprache, die alle für die Programmierung komplexer Programme bei Pascal fehlenden Strukturen besitzt.
Gegenüber Pascal-Dialekten, die die nötigen Sprachelemente in nicht genormter Form einfügen, ist Modula-2 in diesen Dingen bereits vom Konzept her sehr leistungsfähig. Zudem liegt für Modula-2 inzwischen eine Norm vor, die die Sprache und ihren Umfang definiert, man kann sich also darauf verlassen, daß ein Modula-2-Programm auf jedem Rechner läuft, solange man nicht spezielle Funktionen des Betriebssystems wie z.B. das GEM benutzt.
Modula-2 ist übrigens wie C hervorragend für Betriebssystemprogrammierung geeignet. Vergleicht man einige spezielle Features von C mit Modula-2, so ist in meinen Augen Modula-2 der Sieger nach Punkten: Eine wesentliche Fähigkeit von Modula-2 ist die Modulinitialisierung, jedes Modul (sozusagen eine Library) besteht aus Prozeduren, die von anderen Programmteilen benutzt werden können, und einem Initialisierungsteil.
Dies entspricht in C etwa main, nur daß es hier jedes Modul besitzt und dieser Hauptteil automatisch beim Programm-Start ausgeführt wird. Damit hat der Programmierer die Möglichkeit, dafür Sorge zu tragen, daß ein Modul grundsätzlich alle nötigen Initialisierungen selbsttätig durchführt.
Bei C muß grundsätzlichjedes Modul einzeln initialisiert werden, was bei der Programmentwicklung ein höheres Risiko ergibt, daß man diese Initialisierung zu spät oder sogar gar nicht durchführt.
Zum anderen werden Namen aus Modulen grundsätzlich qualifiziert importiert. Das bedeutet, daß Prozeduren gleichen Namens in verschiedenen Modulen existieren können, die durch den Namen des Moduls unterschieden werden.
Hat man beispielsweise in den Modulen Files und Streams die Prozedur Open, so gibt es zwei Möglichkeiten zu spezifizieren, welche der beiden Prozeduren gemeint ist:
FROM Files IMPORT Open;
importiert die Funktion Open, die dann einfach mit ihrem Namen aufgerufen werden kann. Benutzt man in einem Programm beide O/?en-Funktionen, so kann man auch in folgender Weise die Prozeduren spezifizieren:
IMPORT Files, Streams; Der Zugriff auf die Funktionen erfolgt dann mit Files.Open und Streams.Open Diese und noch einige weitere Eigenschaften von Modula-2 führten bei einem C-Programmierer zu der Aussage: ,Dies ist die erste lauffähige Dokumentation, die ich sehe'. Doch kommen wir zu den auf dem ATARI erhältlichen Entwicklungssystemen für Modula-2:
Der Lieferumfang läßt nichts zu wünschen übrig: in zwei Handbüchern wird das gesamte System in vorbildlicher Form erklärt und dokumentiert. Besonders die Dokumentation der sehr umfangreichen Libraries ist als äußerst gelungen zu bezeichnen; wie man es sich wünscht, sind in den Definitionsmodulen die Funktionen ge-nauestens und gut verständlich erklärt. Leider sind jedoch einige Module in mehrere Teile aufgeteilt, was den Überblick etwas schwierig werden läßt.
Insgesamt liegen 117 Module bei, in denen teilweise sehr leistungsfähige Funktionen vorliegen. Leider haben die Betriebssystemaufrufe teilweise andere Namen, als sie von ATARI vorgegeben sind, was ein ständiges Nachschlagen nötig macht.
Dem System liegen zwei Editoren bei, aus denen man einen nach Geschmack
auswählen kann.
Des weiteren liegen einige Utilities bei, die bei der Installation und dem
Betrieb des Entwicklungssystems hilfreich zur Seite stehen.
Auch ein Resource-Construction-Set ist enthalten, so daß alle zur
Programmierung nötigen Werkzeuge bereitstehen.
Auffallend ist MM2CLINK, ein Pseudo-Linker, der Pure-C-Libraries in das
Megamax-Library-Format wandelt, womit mit Megamax Modula-2 und Pure-C mixed
language programmiert werden kann. Dies ist ein nicht zu unterschätzender
Vorteil, hat man doch Zugriff auf Libraries, die ansonsten mühselig in
Modula-2 umgesetzt werden müßten.
MMCLINK ist übrigens Shareware und muß getrennt bezahlt werden,
ist aber mit DM 50,- seinen Preis absolut wert.
Die Oberfläche zeigt sich konventionell: von einer zentralen Shell aus wird das System gesteuert. Daraus ergibt sich der Vorteil, daß man direkt einen Editor seiner Wahl verwenden kann, denn die beiliegenden Editoren sind doch recht gewöhnungsbedürftig. Der eine Editor kann zwar in seiner Tastaturbelegung angepaßt werden, aber der dazu nötige Aufwand ist doch leider recht groß, so daß die Motivation zur Änderung relativ schnell erstickt wird.
Spezialität des Entwicklungssystemes ist das Load-Time-Linking, mit dem während der Entwicklung das erstellte Programm nicht immer vor einem Testlauf gelinkt werden muß. Die Shell erkennt selbsttätig, welche Module geladen werden müssen, um das übersetzte Hauptmodul zu starten. Dabei ist es sehr angenehm, daß bereits geladene Module, z.B. die bereits mit der Shell gelinkten Module, nicht neu geladen werden müssen. Erst bei sehr großen Projekten, die viele Libraries nachladen, wird dieser Prozeß relativ langsam, kann aber durch residentes Laden der wichtigsten Libraries auf einem angenehmen Level gehalten werden.
Das Resident-Laden dieser Libraries und ein großer Teil der Konfiguration der Shell wird über Batches gesteuert, die von der Shell abgearbeitet werden.
Diese relativ einfachen Batches können auch einige angenehme Automatisierungen für den Entwicklungszyklus übernehmen. Lobenswert ist die Tatsache, daß der Quelltext der Shell dem System beiliegt, womit man die Möglichkeit hat, die Shell nach eigenen Wünschen zu erweitern.
Die Quelltexte zu den Libraries sind ebenfalls erhältlich, müssen aber separat bezahlt werden.
Leider fehlt ein Startup-Code für CPX-Module, so daß zur Zeit weder CPX-Module noch XFS- oder XDD-Treiber mit Megamax Modula-2 geschrieben werden können. Der im Source beiligende Startup-Code kann jedoch nach eigenen Vorstellungen angepaßt werden, was sich jedoch aufgrund der etwas mageren Kommentierung als schwierig herausstellt.
Der Compiler ist selbst ein Modul, das im Loadtime-Linking geladen wird. Die Geschwindigkeit des Singlepass-Compilers ist angenehm, und die Turn-around-Zei-ten lassen mit dem Loadtime-Linking einen flüssigen Entwicklungszyklus zu.
Der Compiler kann teilweise direkten FPU-Code erzeugen, wobei leider bei den höheren Operationen, wie z.B. sin und In, Library-Aufrufe gemacht werden.
Leider zeigt der Compiler immer nur einen Fehler an, was die Bereinigung mehrerer Fehler im Quelltext etwas verzögert. Eine Fortsetzung des Compiler-Laufes mit Anzeige aller gefundenen Fehler wäre durchaus wünschenswert.
Angenehm ist die Möglichkeit zu drei verschiedenen Aufrufkonventionen für Prozeduren. Werden die Parameter normalerweise auf dem Modula-Stack übergeben, auf den das Prozessorregister A3 zeigt, so können durch Compiler-Optionen auch eine Registerübergabe wie bei Pure-C oder eine Übergabe über den Stack verwendet werden.
Im Compiler ist ein Mine-Assembler enthalten, der komfortabel in das System eingebunden ist. Vom Assembler aus kann symbolisch auf alle globalen und lokalen Modula-Variablen zugegriffen werden, was sehr angenehm ist, wenn einzelne zeitkritische Routinen einen Hochsprachenteil ersetzen sollen.
Der Debugger von Megamax Modula-2 erfüllt zwar seinen Zweck, ist aber nicht unbedingt als besonders bequem einzustufen. In ein GEM-Fenster werden einige Informationen über die aktuell ausgeführte Programmzeile und Wertzuweisungen ausgegeben. Eine TOS-Version des Debuggers gibt dieselben Meldungen einfach auf den Textbildschirm aus.
Mittels kleiner Änderungen kann man diese Version auf die serielle Schnittstelle ausgeben lassen, was den Komfort erhöht, da man neben dem laufenden Programm die Debugger-Ausgaben getrennt beobachten kann.
Das Megamax-Modula-2-Entwicklungssystem kostet 200,-, die
Library-Quelltexte DM 100,-. Es ist direkt beim Autor erhältlich:
Thomas Tempelmann
Im Lieferumfang von Hänisch-Modula-2 befindet sich ein Ringbuch mit einem SOOseitigen Handbuch zur Dokumentation des Systems, sowie mit weiteren 130 Seiten zur Dokumentation der Libraries, die über die Standardbetriebssystemroutinen hinausgehen. Die Libraries umfassen alle nötigen Betriebssystemaufrufe, wie auch viele Tool-Sammlungen. Angenehm ist die GEMPLUS-Library, mit der fliegende und Fensterdialoge einfach verwaltet werden können. Eine leistungsfähige Window-Library mit allen nötigen Managementfunktionen für eine komplexe Fensterverwaltung gehört ebenfalls dazu.
Der Umfang der Libraries läßt sich auch sehen, insgesamt sind es 15 8 Stück, die gut strukturiert und sinnvoll aufgeteilt sind. Die Libraries sind gut dokumentiert und liegen im Quelltext bei, so daß im allgemeinen keine Fragen offen bleiben. Mit dem beiligenden Startup-Code für CPX-Module können CPX-Module und sogar XFS- oder XDD-Treiber für MiNT geschrieben werden.
Zentraler Teil der Entwicklungsumgebung ist der Editor CLIX. Dieser Editor ist sehr leistungsfähig und läßt kaum Wünsche offen. Jede Funktion des Editors ist über Tastaturkürzel zu erreichen. Bei dem ungeheuren Leistungsumfang des Editors ist es jedoch kaum möglich, sich alle Kürzel zu merken.
Als reinrassige GEM-Anwendung läuft der Editor auflösungsunabhängig und macht keine Schwierigkeiten mit Grafikkarten. Eine besonders angenehme Eigenschaft des Editors ist das Einklappen von Texten. Damit kann man seine Quelltexte übersichtlich halten, indem nur noch die Prozedurköpfe sichtbar sind, ein kaum zu unterschätzender Vorteil bei der Entwicklung großer Projekte.
Auch die meisten anderen Programme, für die der Editor angenehm verwendbar ist, z.B. TeX, kommen problemlos mit den eingeklappten Texten zurecht.
Der Compiler wird als Accessory betrieben, wodurch das zu einem Projekt gehörige Makefile permanent im Speicher gehalten wird. Durch Umbenennen kann er auch als Programm oder sogar als TTP-Programm betrieben werden.
In der Form als Accessory tauscht CLIX mit dem Compiler Nachrichten aus, die die Compiler- oder Make-Läufe steuern. Nach einer ersten Gewöhnungsphase stellt sich dieses System als schnell und bequem zu bedienen heraus.
Der Compiler kann vollständigen direkten Code für 68020 und FPU erstellen, was besonders bei FPU-Befehlen im Gegensatz zu Library-Aufrufen einen erheblichen Geschwindigkeitsvorteil ergibt.
Bei Übersetzungsfehlern werden alle erkannten Fehler angezeigt, und im Editor können die Fehler dann vor dem nächsten Compiler-Lauf in einem Zug korrigiert werden.
Ein kleiner Nachteil des Compilers ist die Beschränkung der Modulgröße auf 32 KB, was darin begründet ist, daß Module grundsätzlich PC-relativ sind. Bei extrem großen Modulen oder Inline-Resources kann es da durchaus passieren, daß man an die Grenzen stößt. In diesem Fall ist man gezwungen, die Module aufzuspalten, was im aktuellen Fall dann durchaus unangenehm und lästig sein kann.
Prozedurparameter werden grundsätzlich über den Stack übergeben, was den Aufrufkonventionen des TOS entspricht, damit wird ohne Probleme die direkte Kommunikation mit Betriebssystemfunktionen ermöglicht.
Interessant ist auch die Möglichkeit, durch eine Compiler-Option eine Prozedur mit einem RTE abschließen zu lassen, womit man direkt in Hochsprache in den Betriebssystemvektoren oder Interrupts hängen kann.
Es gibt zwei Möglichkeiten, Programmteile in Assembler zu schreiben. Onyx ist ein Präprozessor, der im Programm befindliche Assembler-Teile in CODE-State-ments umwandelt. Leider ist mit Onyx kein symbolischer Zugriff auf die umgebenden Modula-Variablen möglich.
Der leistungsfähigere Weg ergibt sich für Besitzer eines DEVPAC-Assemblers: der Babelfish, ein Prä- und Postprozessor, mit dem reine Assembler-Module mit Hilfe des DEVPAC-Assemblers geschrieben werden können. Von Babelfish-Modulen aus kann voll symbolisch auf andere Module und Variablen zugegriffen werden. Der sehr leistungsfähige DEVPAC-As-sembler tut sein übriges für eine angenehme Entwicklung von Assembler-Teilen von Programmen.
Die Präambel und Postambel einer Prozedur mit allen nötigen Symbolen der Umgebung wird dabei durch Anweisungsblöcke für den Babelfish generiert. Dazwischen kann ganz normal in Assembler programmiert werden.
Der Debugger ist das Stück, das am meisten Freude am Hänisch-System aufkommen läßt. Der Runtime-Debugger RTD zeigt sich in einer Oberfläche, wie man sie vom GEM kennt, macht jedoch keinerlei GEM-Aufrufe, was unter TOS für einen Debugger auch nicht möglich ist. Der RTD greift direkt auf die Video-Hardware des ATARI zu, was besonders für Grafikkartenbesitzer angenehm ist, da die Debug-Ausgaben auf dem normalen Bildschirm ausgegeben werden, während das Programm ungestört auf dem Bildschirm mit der Grafikkarte läuft. Ansonsten kann man zwischen dem Programmbildschirm und dem Debugger-Bildschirm hin- und herschalten, wobei auch Bildschirmerweiterungen wie z.B. Autoswitch OverScan unterstützt werden.
Zum Debugging kann man auf Quelltextebene oder auch auf Maschinenebene die Programme durchlaufen. Im Debugger können Breakpoints gesetzt werden, das Programm kann kontinuierlich laufen, während im RTD die aktuell bearbeiteten Zeilen durchlaufen, und man kann im Speichermonitor sehen, was so im Rechner passiert. Das beste ist jedoch die Variablenanzeige, mit der man die lokalen oder globalen Variablen betrachten kann. Bei verketteten Listen kann auch über die Zeigerketten verzweigt werden. Mit diesen Fähigkeiten sind Programmfehler normalerweise schnell gefunden.
Der zweite Debugger ist der Postmor-tem-Debugger PMD. Durch ein einem Programm zugelinktes Modul kann bei einem Programmabsturz ein Speicher-Dump in eine Datei gemacht werden, die anschließend im PMD betrachtet werden kann.
Viele kleine Tools und Utilities runden das gesamte Paket ab: vom RSC-zu-Modula-Konverter für Inline-Resources über Tools zur Auslagerung von Texten des Programmes in externe Dateien, um mehrsprachige Programme zu ermöglichen, bis hin zu einem Programm, mit dem man direkt Definitionsmodule in Hilfedateien für CLIX umwandeln kann.
Sehr schön ist auch DEPGRAPH, mit dem die Anhängigkeitsbäume von Proj ek-ten grafisch dargestellt werden können. Die gesamte Modulhierarchie ist dabei als Baum darstellbar, wodurch auch schnell zirkuläre Importe zwischen Modulen erkannt werden können.
Zu guter Letzt fehlt auch nicht ein Profiler, mit dem ein Programm auf seinen Zeitverbrauch hin begutachtet werden kann. Der Lieferumfang ist zu umfangreich, um ihn hier vollständig zu beschreiben, und selbst nach langem Gebrauch des Systemes erkennt man immer wieder neue Fähigkeiten, die man bei vielen anderen Entwicklungssystemen vergeblich sucht.
Hänisch-Modula-2 liegt kein Resource-Construction-Set bei, was aber eigentlich den Wert des Paketes nicht einschränkt, kommt man als Programmierer doch eigentlich eh nicht an Interface, dem wohl besten RCS auf dem Markt, vorbei. Für den Gelegenheitsprogrammierer wäre es dennoch begrüßenswert, wenn ein einfaches RCS auf denDisketten enthalten wäre.
Hänisch-Modula-2 ist mit 389,- DM für den gebotenen Lieferumfang wirklich seinen Preis wert und kann direkt bei MoSys oder bei Team-Computer bezogen werden.
Für beide Systeme gelten die heutzutage wohl als Pflichtrepertoire zu wertenden Kompatibilitäten zu MultiTOS, MiNT, MagiX! und allen gängigen TOS-Versionen, ein optimierender Linker, die Einstellung der Programm-Flags der gelinkten Programme und Auflösungsunabhängigkeit. Für beide Entwicklungssysteme gibt es die Magic-Library und eine POSIX-Library, mit denen man unabhängig von den unterschiedlichen Libraries Programme schreiben kann, die ohne Änderungen mit beiden Compilern übersetzt werden können.
Beide Entwicklungssysteme erfüllen ihren Zweck und sind leistungsfähige Entwicklungswerkzeuge. Für intensive Programmentwicklungen oder große Projekte ist Hänisch-Modula-2 jedoch wesentlich interessanter, da es in vielen Punkten einfach überzeugender ist. Speziell der extrem leistungsfähige Runtime-Debugger macht die Fehlersuche, die leider meistens einen Großteil der Programmentwicklung in Anspruch nimmt, fast zu einer Freude.
Auch die vielen anderen kleinen Utilities, die mitgeliefert werden, sorgen für erhöhten Komfort beim Programmieren.
Mit der Summe der Möglichkeiten, die Hänisch-Modula-2 im Gegensatz zu Megamax Modula-2 bietet, lautet meine Wahl ganz klar Hänisch-Modula-2. Dennoch ist Megamax Modula-2 ein ernstzunehmendes und gutes Modula-System, das besonders für den schmalen Geldbeutel eine annehmbare Alternative ist.
Steffen Engel
Positiv:
geringer Preis
sehr gut dokumentierte Libraries
C-Linker
Negativ:
zur Zeit kein Startupcode für CPX, XFS, XDD
die Editoren werden heutigen Ansprüchen nicht gerecht
Positiv:
leistungsfähiger Debugger
sehr guter Editor
gute Ausstattung
leistungsfähige Libraries
Negativ:
Module mit max. 32 KB Code