MODULA-2 hat aufgeholt - Alle Compiler im Vergleich

Bild 1: Die TDI-Oberfläche

Für den Atari ST gibt es inzwischen viele ernstzunehmende Entwicklungssysteme. Ein Schwerpunkt liegt - “ST-historisch” begründet - bei den C-Compilern. Im Laufe des letzten Jahres kamen erstaunlich viele Compiler für eine andere Sprache auf den Markt: Modula-2.

In diesem Vergleich sollen die bisher getesteten Pakete gegenübergestellt werden. Detailaspekte, auf die hier nicht eingegangen wird, finden Sie in den Tests der vergangenen Monate beschrieben.

Modula-2, etwas Besonderes?

Modula-2 ist der Nachfolger von Pascal (das sich auf dem ST erstaunlicherweise nicht durchsetzen konnte) und ebenfalls von Niklaus Wirth entworfen. Ein zentrales Konzept der Sprache ist die Modularisierung. Programme werden nicht an einem Stück notiert oder in Include-Dateien aufgeteilt, sondern mit Hilfe von Modulen auch logisch zerlegt. Dabei stellt ein Modul der Außenwelt Objekte wie Prozeduren oder Typen zur Verfügung. Ein Modul, das ein anderes importiert kann diese Objekte benutzen, ohne deren Implementierung zu kennen. Eine Änderung der Implementierung einer importierten Routine verändert das importierende Programm nicht. Solange die Schnittstelle gleich bleibt, muß lediglich neu gelinkt werden. Der Compiler überprüft die Einhaltung der Schnittstelle, vor allem Typübereinstimmungen, sehr penibel.

Gegenüber Pascal ist Modula-2 auch für systemnahe Programme geeignet. Auch wenn es von vielen bestritten wird: In Modula-2 kann man Tricks wie in C anwenden. Allerdings müssen sie expliziert notiert werden und verschwinden nicht in einem unlesbaren Dschungel von Sonderzeichen. Der Programmiererspruch aus USA: “Modula-2’s the best language for hacking” trifft diesen eher unbeachteten Aspekt von Modula-2 haargenau.

Ein weiteres Merkmal von Modula-2 ist unter den auf Mikros weiter verbreiteten Sprachen einzigartig: die Nebenläufigkeit. Als Teil der Sprache sind Standardfunktionen definiert, die das Umschalten von einer Koroutine in eine andere enthalten. Damit lassen sich Programme schreiben, in denen verschiedene Prozeduren quasi-parallel an einem Problem arbeiten. Bei Koppelung der Umschaltung an einen Timer ist Multitasking per Definition in Modula-2 vorhanden. Weiterhin sorgen viele Features der Sprache für lesbare und übersichtliche Programme. Die Eidgenössische Technische

Hochschule in Zürich (ETH) bietet einen Compiler zur Portierung an. Eine Modula-Implementierung für den ST ist also eigentlich ein Kinderspiel.

Trotzdem sind die für den Atari ST angebotenen Compiler sehr unterschiedlich, und auch nicht alle beruhen auf dem ETH-Stammvater. In diesem Vergleich werden alle uns zugänglichen Systeme vorgestellt und die jeweiligen Besonderheiten herausgestrichen.

Modula-2 Benchmarks

Nr. TDI V3.0 Jefferson Megamax Softwave SPC M2 testet ...
1 0:07 0:07 0:07 0:04 0:02 Prozeduraufruf
2 1:42 1:33 2:59 1:35 1:27 Addition
3 1:21 1:18 1:58 1:20 1:12 Increment
4 1:47 1:38 2:59 1:40 1:32 Additionsoptimierung
5 1:27 1:23 2:08 1:25 1:17 Increment als Vergleich
6 2:09 1:57 3:48 2:01 1:51 INTEGER-Addition
7 2:09 1:57 3:48 2:01 1:51 CARDINAL-Addition
8 1:11 1:18 1:42 1:05 1:12 FOR-Schleife
9 1:21 1:02 1:42 1:05 0:56 REPEAT-Schleife
10 1:21 1:18 1:57 1:20 1:12 WHILE-Schleife
11 1:04 0:54 1:15 0:38 0:48 INTEGER-Parameter
12 1:04 0:54 1:17 0:38 0:48 INTEGER VAR-Parameter
13 1:06 0:59 2:19 0:33 0:53 RECORD-Parameter
14 0:34 0:30 0:41 0:20 0:24 RECORD VAR-Parameter
15 0:49 0:49 1:33 0:42 0:43 Konstanten- Optimierung
16 0:51 0:51 1:33 0:44 0:45 Konstanten-Optimierung
17 1:28 1:26 2:06 1:19 1:20 Expression-Optimierung
18 1:42 1:22 1:59 1:15 1:16 Expression-Optimierung
19 0:37 0:36 0:55 0:30 0:30 Zwischenergebnis-Optimierung
20 0:37 0:35 0:55 0:30 0:30 Zwischenergebnis-Optimierung
21 0:09 0:11 0:13 0:09 0:05 IF-Statement
22 0:13 0:13 0:16 0:11 0:07 IF durch CASE ausgedrückt
23 0:38 0:33 0:41 0:28 0:27 CASE-Statement
24 0:40 0:39 1:03 0:38 0:33 CASE durch IF ausgedrückt
25 0:47 1:03 2:09 0:45 REAL-Arithmetik
26 2:05 1:32 2:18 2:07 LONGREAL- Arithmetik
27 1:52 5:42 3:36 REAL-Library
27a 5:39 2:35 35:40 3:30 LONGREAL-Library
28 1:21 1:21 0:40 0:30 1:40 String-Library
29 2:10 2:07 2:13 1:48 1:40 ARRAY-Zugriffe
30 0:09 0:10 0:17 0:19 0:04 RECORD-Zugriffe

Alle Zeiten mit tirae-Kommando von Guläm gemessen SPC Modula mit 200Hz-Zähler gemessen

Tab. 1: Alle Benchmarks auf einen Blick

TDI Modula

Der TDI-Compiler kam als erster auf den ST-Markt und war lange Zeit das einzige Paket. Er liegt inzwischen in der Version 3.0 vor und wurde auch schon auf den Amiga portiert. Daher ist er sicherlich der fehlerfreieste Compiler und hat bewährte und korrekte Bibliotheken. Die Version 3.0 ist ein Fünf-Pass-Compiler. Es soll auch eine neuere Revision als Ein-Pass-Übersetzer nach dem neuesten Modula-Standard geben, für die ich allerdings bis heute keine Update-Benachrichtigung bekommen habe.

Das System kostet circa DM 300 und wird auf zwei einseitigen Disketten mit Handbuch geliefert.

Die Oberfläche des Systems stellt die Text- und Codedateien als Icons dar (Bild 1). Beim Anklicken eines dieser Symbole wird je nach Dateiart der Editor, Compiler oder Linker aufgerufen. Die Bedienung ist sehr bequem und zweckmäßig. Im Vergleich zur Megamax-Shell fehlen edoch Kommandos zur Datei Verwaltung.

Sämtliche Einstellungen für das System werden in einem Accessory vorgenommen (Bild 2). Die Suchpfade gelten dabei für alle Systemprogramme, also für die Oberfläche, den Compiler, Linker und Debugger.

Der mitgelieferte Editor ist gewöhnungsbedürftig. Er befindet sich ständig im Einfügemodus und wird sicher keine Geschwindigkeitsrekorde aufstellen. Nach längerer Arbeit damit wird man zum Verschieben von Textblöcken oder zum Vervielfältigen von Zeilen die Kombination Löschen-UNDO effizient einsetzen.

Sehr gut verarbeitet der Editor beim Übersetzen entstandene Fehlermeldungen. Kommt der Cursor an eine Fehlerstelle, erscheint die Meldung als Klartext in der Info-Zeile des Editor-Fensters. Der Compiler arbeitet mit seinen fünf Pässen bedächtig und wird von den anderen Ein-Pass-Übersetzern übertroffen. Der erzeugte Code ist recht gut, könnte aber noch einige Optimierungen vertragen.

Tabelle 1 finden Sie die Benchmark-Ergebnisse aller Systeme. TDI wird - abgesehen von Megamax - von allen neueren Compilern übertroffen.

Die mitgelieferten Bibliotheken sind bei den Überarbeitungen nahezu unverändert geblieben. Es sind neben den Standardmodulen Bibliotheken für AES, VDI, GEMDOS und den systemnahen BIOS-Bereich vorhanden. Module für Textfenster oder die Eventverwaltung müssen mit dem “Toolkit” extra hinzugekauft werden. Im Vergleich mit Megamax oder SPC sind die Libraries zu mager geraten.

Der Linker arbeitet auf Wunsch optimierend und entfernt so nicht benutzte Prozeduren. Die endgültige Programmgröße ist sehr gering; kein Modula-Linker arbeitet so effizient.

Bild 2: Sämtliche Einstellungen für das TDI-Modul-System werden in einem Accessory vorgenommen.

Ein Debugger ist im eigentlichen System nicht enthalten. Mit dem Toolkit (s.u.) bietet TDI jedoch einen Post-Mortem-Debugger an. Er arbeitet mit einem Speicherdump nach einem Programmabsturz und kann alle Datenobjekte und den Sourcecode anzeigen. Das Programm ist ein direkter Abkömmling des ETH-Debuggers und könnte an einigen Stellen verbessert werden. Gegenüber den Möglichkeiten, die Megamax bietet, schränkt das Post-Mortem-Konzept natürlich die Anwendungsbreite ein.

Das Handbuch ist nur in englische Sprache verfügbar, dafür aber als einziges mit einer praktischen Spiralbindung versehen. Alle Fragen werden geklärt, es hat sich auch als Nachschlagwerk bewährt. Als Ergänzung zu dem reinen Compiler-System wird der “Toolkit” angeboten. Er enthält eine Reihe von Modulen, mit denen die GEM-Programmierung erheblich vereinfacht wird. Dies reicht von der Eventverwaltung bis zu Textfenstern. Weiterhin vorhanden ist ein Debugger, der nach einem Programmfehler eingesetzt wird und ein Post-Mortem-Debugging auf Source-Code-Ebene bietet. Schließlich enthält der Toolkit das Resource-Construction-Set MMRCP.

Der große Vorteil des TDI-Systems liegt in seiner langen Marktpräsenz. Fehler sind in der dritten Version wohl nicht mehr vorhanden. Der optimierende Linker erzeugt überaus kurze Programme und ist nach wie vor der beste Modula-Linker für den ST.

Im Vergleich mit den anderen Modula-Paketen schneidet TDI bei der Übersetzungsgeschwindigkeit, beim erzeugten Code und im Lieferumfang schlecht ab. Erst mit dem Toolkit, der extra gekauft werden muß, kann sich das System ernsthaft mit der Konkurrenz messen.

Jefferson Modula

Bild 3: Jefferson-Modula benutzt die Guläm-Shell

Jefferson-Modula ist bisher nur als Import erhältlich. Wegen seines geringen Preises von $50 handelt es sich dabei um einem Preisbrecher. Es ist das einzige System unter DM 100 und wird auf einer einseitigen Diskette geliefert.

Als Umgebung wird bei Jefferson die leistungsstarke Public-Domain-Shell Guläm verwendet (Bild 3). Wer auf GEM-Umgebung verzichten kann und will erhält eine erstklassige Kommandoshell, die bei richtiger Benutzung eine große Unterstützung ist. Im Vergleich mit den aufwendigen GEM-Shells anderer Systeme wirkt diese Ausstattung allerdings etwas altertümlich.

Ein extra Editor wird nicht mitgeliefert. Das ist allerdings auch nicht notwendig, da der Guläm einen EMACS-Editor eingebaut hat. Ein wirkliches Problem ist dagegen die amerikanische Tastaturanpassung, die für STs mit German-Keyboard absolut unverwendbar ist. Guläm läßt sich allerdings entsprechend patchen - Anpassungsarbeiten, die man bei einem Import in Kauf nehmen muß.

Der 1-Pass-Compiler arbeitet wie der Linker eher schweigsam (Bild 4). Er liefert einen überraschend guten Code, der die erheblich teureren Systeme TDI und Megamax abhängt.

In den Benchmarks macht Jefferson eigentlich eine gut Figur. Alle Ergebnisse lassen eine gute Optimierung erkennen und kommen den Spitzenreitern SPC und Softwave nahe.

Allerdings implementiert Jefferson Modula-2 nicht komplett: Die Coroutinen sind dem Compiler nicht bekannt und werden auch nicht durch ein Modul zugänglich gemacht. Ebenso fehlen die LONGREALs, so daß der Sprachumfang doch merklich eingeschränkt ist.

Bild 4: Compiler und Linker des Jefferson-Modula bei der Arbeit

Die mitgelieferten Bibliotheken sind nicht sehr umfangreich. Es sind die Standard-Module vorhanden; sie werden ergänzt durch die normalen Bibliotheken für AES, VDI, GEMDOS und BIOS. Module für höhere GEM-Funktionen sind nicht vorhanden und müssen selber geschrieben werden.

Fehlerfrei sind die Module sicher nicht; Versuche, das InOut-Modul zu benutzen, führten zu einem Systemabsturz. Durch Fehler und Ungereimtheiten macht die Auslieferung einen etwas schlampigen Eindruck.

Der Linker arbeitet zufriedenstellend und liefert nicht auf Größe optimierte Programme.

Nennenswerte Debugging-Hilfen gibt es nicht. Im Gegenteil: Um aus den Compiler-Fehlermeldungen Klartext zu erzeugen, ist der Lauf eines kleinen Programms namens OOPS notwendig, was die Programmentwicklung unnötig erschwert.

Das Handbuch ist in der Version für $50 ein Heftchen mit 26 Seiten. Ein erweitertes Handbuch muß zusätzlich gekauft werden. Für die Installation des Systems reicht es aus, geht allerdings kaum ins Detail. Gegenüber den ausführlichen Anleitungen der anderen Systeme ist Jefferson-Modula sehr schlecht dokumentiert.

Jefferson-Modula ist das preisgünstigste Produkt für den ST. Ob der Niedrigpreis wirklich die Abstriche bei der Ausstattung rechtfertigt, ist zweifelhaft. Auch durch das Fehlen eines bundesrepublikanischen Vertriebs fällt Jefferson als wirkliche Alternative aus.

Megamax Modula

Megamax-Modula-2 war sehr lange angekündigt und ist in diesem Frühjahr endlich erschienen. Für DM 398,- erhält man vier teils doppelseitige Disketten und ein Handbuch im Ringordner.

Bild 5: Megamax Modula bietet die beste Shell.

Die Umgebung für Megamax-Modula ist mit über 200 KiloByte die größte, aufwendigste und leistungsstärkste unter den getesteten Paketen (Bild 5). Das Programm stellt praktisch alle Funktionen des GEM-Desktops zur Verfügung, so daß man die Shell nicht zum Kopieren oder Löschen von Dateien verlassen muß.

Alle Funktionen werden über die Icons aufgerufen, wobei es die meisten Aktionen auch als Tastenkombinationen gibt. Um Ladezeiten zu sparen, lassen sich Module oder Programm auch resident im Speicher halten. In der abgebildeten Situation sind der Compiler und der Editor geladen, so daß der Turn-Around-Edit-Compile ohne Massenspeicherzugriff abläuft.

Mit einer umfangreichen Installationsdatei läßt sich das System sehr flexibel an die Ordnerstrukturen anpassen. Hier lassen sich auch Voreinstellungen setzen oder ein anderer Editor problemlos einbinden.

Die Shell übernimmt noch ein Konzept, das die Programmentwicklung beschleunigen soll: das Load-Time-Linking. Dabei müssen Programme zum Starten nicht mehr durch einen Linker geschickt werden, vielmehr bindet die Shell beim Ladevorgang alle benötigten Module zusammen. Ergebnis ist eine schnellere Programmentwicklung, da kein extra Linkerlauf notwendig ist.

Als Editor liegt dem System eine Version des Toolbox-Editors bei, den Application Systems auch einzeln als C-Quelle anbietet. Er ist nicht besonders auf Modula zugeschnitten, fügt sich allerdings recht gut in das System ein.

Der Compiler kann direkt vom Editor aufgerufen werden und auch die Anzeige von Fehlerstellen geht problemlos. Das Programm funktioniert ansprechend schnell und erfüllt seine Aufgabe. TEM-PUS-Fans können ihren Editor problemlos einbinden.

Der Compiler ist die Schwachstelle des Systems. Zwar kann er dank Assemblerprogrammierung und 1-Pass-Konzept mit rasender Geschwindigkeit arbeiten, der erzeugte Code erwies sich aber als langsam und kaum optimiert. Lediglich die LONGREAL-Arithmetik kann überzeugen.

In der Benchmark-Tabelle ist Megamax die Schlußleuchte. Die Zeiten liegen weit hinter denen der anderen Systeme. In einzelnen Fällen wird glatt die doppelte Rechenzeit benötigt.

So komfortabel die Entwicklungsumgebung auch sein mag, das eigentliche Ergebnis der Programmierarbeit läßt zu wünschen übrig. Application Systems hat an dieser Stelle Besserung versprochen; die Optimierung lag für diesen Artikel jedoch noch nicht vor.

Für zeitkritische Anwendungen wurde die Sprache um einen Assembler erweitert. In einem ASSEMBLER-END-Block können alle 68000-Mnemoniks verwendet werden, wobei der Zugriff auf Modula-Variablen problemlos möglich ist.

Bild 6: Single-Steps mit Megamax Modula

Megamax liegen die umfangreichsten Bibliotheken der getesteten Systeme bei. Sie gehen weit über die “normalen” Libraries mit AES/VDI sowie GEMDOS/BIOS-Zugriffen hinaus.

Funktionen für eine vereinfachte AES-Programmierung erlauben Textfenster, eine vereinfachte Eventprogrammierung und komfortablen Zugriff auf Objektbäume.

Weiter finden sich sehr viele Routinen, die das Programmieren erheblich beschleunigen. Zugriff auf Listenstrukturen, komfortable Konvertierungroutinen für Zahlen und Strings sind nur ein paar der vielen mitgelieferten Module.

Auch wenn die Shell ein Load-Time-Linking erlaubt, liegt für Stand-Alone-Programme ein separater Linker bei. Er arbeitet nicht optimierend und erzeugt somit Programme, die größer als notwendig sind. Ein optimierender Linker wird ab Anfang Juli erhältlich sein.

Das Debugging gestaltet sich bei Megamax sehr komfortabel. Bei einem Laufzeitfehler erscheint zunächst eine Alertbox, die einige Informationen über die Absturzstelle ausgibt und eine Inspektion der Ausrufkette ermöglicht.

In einer zweiten Alertbox kann man dann entscheiden, ob der Fehler ignoriert, das Programm abgebrochen oder der Editor gestartet werden soll. Der Cursor wird dann im Quelltext auf die fehlerhafte Stelle gesetzt.

Aber auch schon während des Programmlaufs ist eine Überwachung möglich. Das Programm läuft dann in einem Single-Step-Modus und gibt in einem Fenster das Ergebnis des jeweils berechneten Ausdrucks aus (Bild 6). Der Debugger erlaubt einige Analysen über Registerinhalte oder Codeadressen. Die Debug-Optionen können auch über Steuervariablen des Debug-Moduls vom Programm selber verändert werden.

Das Handbuch ist sehr gut gelungen. Den größten Teil nehmen, wie sonst auch, die Listings der Definitions-Module der Bibliotheken ein. Dabei werden die Routinen in Kommentaren so gut dokumentiert, daß kaum Fragen offen bleiben. Der erste Teil erläutert die Systembenutzung und beschreibt den Compiler. Dabei bekommt der Anfänger eine leicht verständliche Anleitung und der Experte alle Fakten, die notwendig sind, um z.B. mit dem Assembler auf Modula-Objekte zuzugreifen. Ein sehr gutes Handbuch mit umfangreichem Register, das für andere Systeme Vorbild sein sollte. Megamax liegt ein Resource-Construction-Set standardmäßig bei. Es handelt sich um das NRSC von Kuma in einer deutschen Version, die auch unter Blitter-TOS läuft. Falls das eingebaute Debugging nicht ausreicht, kann man auch den mitgelieferten TEMPLMON-Monitor verwenden, der wohl die allerletzten Fehler aufzeigt.

Megamax unterstützt die Programmentwicklung hervorragend. Shell und Bibliotheken sind die Glanzstücke des Pakets. Abstriche müssen allerdings beim erzeugten Code gemacht werden.

Softwave Modula

Das mit DM 199,- preiswerteste, direkt erhältliche System wird auf einer Diskette geliefert. Dazu kommt ein Handbuch im Ringordner.

Bild 7: Softwave Modula wird über eine Dialogbox gesteuert

Das System integriert alle Bestandteile in einem Programm. Das integrierte Paket wird über eine Dialogbox (Bild 7) gesteuert. Beim Festlegen der Ordnerstrukturen werden alle Dateien auf Abhängigkeiten hin untersucht. Die Auswahl einer Arbeitsdatei per Maus in der Fileliste bringt dann alle abhängigen Module in normaler Schrift auf den Bildschirm.

Die Shell hat ein Make eingebaut, bei dem aufgrund der festgestellten Abhängigkeiten alle zusammenhängenden Module automatisch neu compiliert werden, falls notwendig.

Der Editor ist sehr einfach programmiert und verfügt noch nicht über eine Menüsteuerung. Als Sprachunterstützung sind Textmakros möglich, mit denen Gerüste für oft verwendete Strukturen oder Schlüsselworte automatisch erzeugt werden können.

Der Compiler erzeugt recht gut optimierten Code. Schwächen haben allerdings noch die Fließkommaoperationen, bei denen das System das Schlußlicht bildet. Nach den Benchmarks hat es zusammen mit SPC die beste Codegenerierung. Nach und nach soll der Übersetzer auch an andere Prozessoren der Motorola-Familie angepaßt werden, so daß er eventuelle Zusatzprozessoren unterstützt (Bild 8).

Einige kleinere Spracherweiterungen implementieren einen STRING-Typ und zusätzliche eingebaute Funktionen. Allerdings sind diese Features in der aktuellen Version noch nicht sehr nützlich.

Die Bibliotheken enthalten wie bei TDI nur die Standardmodule und die normalen AES/VDI- und GEMDOS/BIOS-Libraries.

Unter dem Montage-Icon verbirgt sich der Linker. Zunächst löst das Make notwendige Übersetzungen aus, worauf der Linker dann die Module zusammenbindet. Er arbeitet nicht optimierend. Besondere Debugging-Möglichkeiten gibt es nicht. Es ist allerdings ein Debugger auf Source-Code-Ebene angekündigt. Zum Zeitpunkt dieses Vergleichs lag er jedoch noch nicht vor.

Bild 8: Softwave Modula soll auch an andere Motorola-Prozessoren angepaßt werden.

Das Handbuch erläutert ausreichend die Benutzung des Systems. Ein längeres Kapitel soll in die Modula-Programmierung einführen, und abschließend werden wie üblich die Definitionsmodule der Libraries aufgelistet. Dabei sollte etwas mehr an erläuternden Kommentaren geboten werden. Die Druckvorlage für das Handbuch ist mit einem Matrixdrucker erstellt - vielleicht sollte der Hersteller hier einen Laserdrucker verwenden.

Softwave-Modula ist ein System, das sehr gut optimierten Code liefert. Die Systemintegration und das Make vereinfachen die Programmentwicklung. Schwachpunkte sind die nicht sehr umfangreichen Bibliotheken, die Real-Arithmetik und der noch nicht komplette Editor. Durch den Preis bietet das System aber einen kostengünstigen Einstieg in Modula-2.

SPC Modula

SPC-Modula ist für DM 349,- auf einer Diskette erhältlich. Das System ist eine direkte Portierung des ETH-Compilers. Als Umgebung wird eine tastenorientierte Shell mitgeliefert (Bild 9). Sämtliche Systemprogramme werden mit einem Buchstaben aufgerufen, wobei die Shell die wahrscheinlich nächste Aktion als Default anbietet. Wenn sich die Softwareentwicklung im herkömmlichen Edit-Compile-Test-Zyklus vollzieht, können alle Aufrufe durch mehrmaliges Drücken von < Return > durchgeführt werden.

Der Shell fehlen dafür jegliche Dateioperationen und der grafische Komfort, den vor allem Megamax bietet.

Bild 9: SPC Modula arbeitet mit einer tastenorientierten Shell.

Der mitgelieferte Editor unterstützt die Entwicklung von Modula-Programmen besonders. Die “Language-Support”-Option bewirkt, daß alle in Kleinbuchstaben eingegebenen Wörter möglichst früh in Modula-Schlüsselworte umgewandelt werden. Um “PROCEDURE” einzugeben, reichen dann schon die Buchstaben “pr”.

Ebenfalls strukturunterstützend lassen sich die Textmakros verwenden, die auf den Zehnerblock gelegt werden.

Der Compiler arbeitet schnell und liefert gut optimierten Code. Seine Benchmarks werden nur noch vom Softwave-System übertroffen. Dabei sind die REALs mit einfacher Genauigkeit etwas langsam, da sie vor der Berechnung in LONGREALs umgewandelt werden.

Die gemessenen Zeiten sind mit dem Softwave-System vergleichbar und machen SPC zu einem sehr guten Produkt, soweit es um die Codegeschwindigkeit geht.

Die Bibliotheken umfassen den Standard und die gewohnten Atari-Libraries mit AES/VDI und GEMDOS/BIOS. Dazu kommen einige Hilfsmodule mit erweiterten Funktionen für Strings oder das Filesystem.

Für fensterorientierte Anwendungen existiert das “SSWiS”-Modul, das eine rechnerunabhängige Programmierung von grafischen Oberflächen ermöglicht.

Die Bibliotheken könnten eine hohe Portabilität von Programmen ermöglichen, falls SPC auch auf andere Rechner übertragen werden sollte. Damit wird natürlich ein Geschwindigkeitsverlust in Kauf genommen. Ein Fenstersystem, das eine völlig GEM-unabhängige Schnittstelle hat, verursacht natürlich mehr Rechen-Overhead als ein spezialisiertes GEM-Fenstermodul.

Ein Linker lag zum Zeitpunkt dieses Vergleichstests nicht vor. Er ist angekündigt und soll im Sommer geliefert werden. Dadurch sind im Moment keine Stand-Alone-Programme möglich (man denke nur an Accessories), und SPC hätte meiner Meinung nach vielleicht zunächst andere Bestandteile zurückstellen und das Paket von Anfang an in den Grundfunktionen komplett ausliefern sollen. Als Debugger steht der Post-Mortem-Debugger aus dem ETH-System zur Verfügung (Bild 10). Er wird nach einem Programmabsturz eingesetzt und erlaubt dann die Inspizierung des Programmzustands einschließlich Source-Anzeige. Er entspricht Uber weite Teile dem TDI-Debugger.

Bild 10: Der Post-Mortem-Debugger des SPC Modula.
  TDI V3.0 Jefferson Megamax Softwave SPC-Modula
Compiler-Pässe 5 i i 2 1
Geschwindigkeit lt. Hersteller k.A. k.A. 5000 12000 5000
INTEGER/CARDINAL/Bits 16 16 16 32 16
LONGINT/LONGCARD/Bits 32 32 32 32 32
REAL/Bits 32 32 64 32 32
LONGREAL/Bits 64 64 64 64 64
SETS/maximale Elemente 65 536 16 65 536 32 16
BITSET/maximale Elemente 16/32 16 16 16 16
Zusätzliche Bibliotheken nur im Toolkit nein ja nein Ja
Resource-Construction-Set nur im Toolkit nein ja nein nein
Systemgröße/KiloByte 620 760 1680 350 520
Handbuchstärke/Seiten 370 26 380 160 210
Preis 298,- $50 398,- 199,- 349,-

Tabelle 2: Weitere Daten im Überblick

Das Handbuch erläutert das System brauchbar. Ein gesonderter Teil soll in die Modula-Programmierung einführen. Dabei sind zum Zeitpunkt dieses Vergleichs einzelne Kapitel noch als “wird nachgereicht” angekündigt.

Die Dokumentation der mitgelieferten Bibliotheken enthält leider zu wenig Kommentare, um alle Fragen zu klären. So wird z.B. das Modul “Process”, das die Coroutinen auf einem logisch höheren Level anbietet, so unzureichend beschrieben, daß eine praktische Arbeit damit nicht möglich ist.

SPC-Modula hat gegenüber den Konkurrenten aus der Spitzengruppe bei der Codegeschwindigkeit die besseren Bibliotheken zu bieten. Megamax, das in dieser Hinsicht noch besser ist, kann bei der Codeerzeugung nicht mithalten.

SPC ist ein gutes System, bei dem zwar noch nicht alles optimal ist, das aber gute Leistungen in allen Aspekten bietet.

Das Traumsystem

Da sich kein System als in allen Bestandteilen optimal bezeichnen läßt, möchte ich noch kurz das ultimative Modula-System für den ST skizzieren. Zusammenkommen müßte eine Oberfläche wie bei Megamax, die erheblich mehr kann, als nur einen komfortablen Wechsel zwischen den Paket-Bestandteilen zu ermöglichen. Dazu käme ein Compiler, der schnell läuft und einen Code wie Softwave oder SPC liefert.

Der beste Linker ist im Moment bei TDI zu finden, bei den Bibliotheken hat Megamax das meiste zu bieten, ebenso wie beim Debugging und dem Handbuch.

Ein Resource-Construction-Set wäre auch unabdinglich. Und um diesen kleinen Ausflug ins Reich der Phantasie zu vervollständigen käme ein Preis wie bei Softwave oder gar Jefferson in Frage.

In den Tabeilen 2 und 3 finden Sie weitere technische Daten der Systeme und nochmals alle Stärken und Schwächen auf einen Blick.

Anmerkungen

Nachdem nun eine Reihe von Compilern vorliegt, möchte ich einige allgemeine Bemerkungen zu den Modula-Systemen für den ST machen.

Man möchte meinen, daß Modula-Programme portabel sind, wenn systemabhängige Funktionen in eigenen Modulen versteckt werden. Doch kaum ein Programm läßt sich unter den beschriebenen Compilern ohne Überarbeitung austauschen. Selbst die kleinen Benchmarkprogramme, die von vornherein als reinstes Standard-Modula formuliert wurden, müssen immer wieder angepaßt werden.

Dafür gibt es mehrere Gründe. Da sind zunächst die unterschiedlichen Größen von INTEGER, CARDINAL und REAL. Wirth hat keinerlei Aussagen darüber gemacht, ob nun ein INTEGER zwei oder vier oder gar acht Bytes belegen soll. Dafür gibt es z.B. die unterschiedlichen Typen" SHORTINT, INTEGER und LONGINT, die eine gewisse Abstufung erlauben.

Bei den Modula-Implementierungen legen sich einige Entwickler auf eine Länge fest, was zur Folge hat, daß z.B. INTEGER völlig identisch ist mit LONGINT. Doch ein Programmierer kann verlangen, daß er mittels der Typangabe auch bestimmen kann, welche Objektgröße verwendet werden soll. Wenn man als Grundtyp ein 32-Bit-INTEGER benutzt, sollte zumindest auch ein SHORTINT vorhanden sein, das 16 Bit groß ist.

Ähnlich ist die Lage bei den REAL-Implementierungen. Wenn hier REAL immer mit doppelter Genauigkeit berechnet wird, ist der Geschwindigkeitsnachteil offensichtlich. Man kann verlangen, daß ein Modula-Compiler alle denkbaren Grundtypen auch wirklich implementiert.

Die Bibliotheken sind der Dreh- und Angelpunkt von Modula-Programmen. Daß Wirths Vorschlag für eine Standardbibliothek nicht ausreicht, ist völlig klar. Doch immerhin wurde damit ein minimaler Standard festgesetzt, und es ist unverständlich, warum niemand ihn einhalten kann. Auch wenn ein System bessere Bibliotheken für Standardaufgaben enthält, würde ich erwarten, daß wegen der Portabilität auch die rudimentären Wirth-Module vorhanden sind.

Eine weitere Unsitte bei den Modula-Compiler auf dem ST sind eigene Spracherweiterungen. Das Hinzufügen eines STRING-Typs z.B. ist nicht einfach ein “Feature” des Systems, es ist vielmehr eine grundlegende Änderung der Sprache an sich. Das gleiche gilt für einen eingebauten Assembler. Erweiterungen gehören in eigene Module. Wenn sich Routinen nur schlecht als Prozeduren formulieren lassen, z.B. wegen wechselnder Parameteranzahl, muß man eben Modula-Tricks anwenden oder das Konzept überdenken. Ein Wildwuchs von Designänderungen kann der Sprache nur schaden und nutzt das Modul-Konzept nicht aus.

Bei umfangreichen Bibliotheken wächst der Verwaltungsaufwand auf den Massenspeichern enorm an. Hat man 50 Module, so entstehen bei getrennten Symbol- und Linkdateien schon 1 OOFiles, die im Zugriff sein müssen. Schon jetzt ist die Arbeit mit nur einem Diskettenlaufwerk praktisch unmöglich, richtig komfortabel wird’s erst mit Festplatte. Vielleicht sollten Implementierungen auf dem ST ein gepacktes Libraryformat verwenden, wie es auch auf Großrechnern zu finden ist. Alle Standardmodule gepackt in eine Datei STANDARD.LIB mit einigen simplen Zugriffsmechanismen für Compiler und Linker, und schon wäre Benutzern mit Diskettenlaufwerken erheblich geholfen.

Bis jetzt gibt es praktisch keine Tools für die Modula-Systeme. Zwar ist ab und zu ein Make oder Cross-Referenz vorhanden, aber was ist das schon? Warum macht kein Entwickler mehr aus seinen Sourcen? Wie wäre es mit einem Syntax-Checker, mit Analyseprogrammen oder mit einem syntaxgesteuerten Editor? Alles Dinge, die mit einem selbstgeschriebenen Compiler einfach zu realisieren wären.

Trotzdem...

Bei allen offenen Wünschen, die vielleicht übersteigert aussehen mögen, sind ST-Besitzer sehr gut mit Modula-Compilern versorgt. Für fast alle Anwendungsschwerpunkte bietet der Markt genügend Auswahlmöglichkeiten.

C ist und bleibt eine feste Bank bei den Entwicklungspaketen, doch langsam aber sicher ist Modula-2 der große Konkurrent geworden, wenn es um Programmierung geht.

TDI V3.0

+ Mehrmals überarbeitetes System
+ Optimierender Linker
- Zusätzliche Ausgaben für Toolkit

Jefferson

+ Niedrigpreis
- Keine Coroutinen
- Wenig Bibliotheken
- Schlampige Auslieferung
- Muß in USA gekauft werden

Megamax

+ Umfangreiche Bibliotheken
+ Komfortable Oberfläche
+ Sehr gutes Handbuch
- Langsamer Code

Softwave

+ Optimierender Compiler
+ Integriertes System
+ eingebautes Make
- wenig Bibliotheken

SPC-Modula

+ Hochoptimierender Compiler
+ überzeugende Oberfläche
+ Zusätzliche Bibliotheken

RT



Aus: ST-Computer 07 / 1988, Seite 28

Links

Copyright-Bestimmungen: siehe Über diese Seite