Der zweite Streich: Der Compiler Megamax-Modula II im Test
In Programmierkreisen bestens bekannt, von vielen Fachzeitschriften gelobt: der C-Compiler von Megamax. Jetzt kommt der zweite Streich: »Megamax-Modula«. Die Spannung ist groß, ob sich »Megamax« als Synonym für hervorragende Compiler behauptet.
Bereits in der Märzausgabe der 68000er warfen wir einen kurzen Blick auf die Vorversion von Megamax-Modula. Manche Fragen blieben zu diesem Zeitpunkt unbeantwortet. Wir wollen Ihnen aber nicht die Antworten schuldig bleiben.
Der Urvater von Pascal, Professor Niklaus Wirth, entwickelte die Programmiersprache Modula-II als deren Nachfolger. Was weniger bekannt ist: Das Team um Professor Wirth entwarf Modula-II nicht nur als reine Programmiersprache, sondern gab ihr auch eine Arbeitsumgebung mit. Schaut man sich den Modula-Computer »Lilith« mit der zugehörigen Software näher an, ist man schnell vom Komfort der Hilfsmittel, wie zum Beispiel Editor und Debugger, begeistert.
Eine ähnliche Philosophie vertritt auch Megamax-Modula. Der Compiler tritt in den Hintergrund, entscheidend ist die Entwicklungsumgebung.
Wie die Autoren von Megamax-Modula sehr richtig erkannten, gehört zum Komfort auch der Aspekt der Geschwindigkeit. Was nützen die besten Tools, der beste Debugger, wenn ein langsamer Compiler auf den Nerven des Programmierers herumtanzt?
Die Entwickler zogen zwei Konsequenzen: Erstens sollte der Compiler schnell sein. Zweitens, und das ist bei großen Programmen wichtiger, verbannte man den Linker aus dem Entwicklungszyklus.
Auf den ersten Blick erscheint ein fehlender Linker als Widerspruch zur ausgeprägten Modularität der Sprache. Der Linker fehlt nicht wirklich, er tritt nur in den Hintergrund. Wenn der Programmierer ein Programm aus der Shell startet, tritt der sogenannte Loader in Aktion. Er lädt alle nötigen Module in den Arbeitsspeicher und bindet sie dort. Dieses progressive Konzept nennt man Load-Time-Linking oder frei übersetzt: Binden zur Ladezeit.
Da das Linken im Arbeitsspeicher geschieht, beansprucht die Linkzeit auch bei großen Programmen meist nicht mehr als 1 bis 2 Sekunden. Diese enorm kurze Linkzeit erreicht Megamax-Modula unter anderem dadurch, daß die Shell in der Lage ist, compilierte Module im Speicher zu halten.
Ist die Programmentwicklung abgeschlossen, bindet man es mit dem »echten« Linker. Damit ist es auch ohne die Shell lauffähig. Der mitgelieferte Linker hat derzeit einen Haken: Er optimiert nicht.
Das ist gravierend, da Megamax-Modula besonders ausgefeilte und dadurch umfangreiche Bibliotheken bereitstellt. Wenn man zum Beispiel ein Programm schreibt, das lediglich ein Zeichen via InOut auf dem Bildschirm ausgibt, so zieht der Import der Prozedure Write einen enormen Rattenschwanz von Importen hinter sich her. Es ist fast unmöglich, ein Programm zu schreiben, das weniger als 60 KByte belegt. Ein einfaches Programm, das einige Funktionen aus der String-Bibliothek, einige direkte TOS-Aufrufe, sowie das Modul ArgCV benutzt, verwandelt der Linker in ein Programm von immerhin 16 KByte Länge.
Kurz vor Redaktionsschluß erfuhren wir, daß ein optimierender Linker inzwischen fertiggestellt sei. Da er uns nicht mehr rechtzeitig erreichte, um getestet zu werden, müssen wir Sie in dieser Hinsicht auf die nächste Ausgabe vertrösten. Aber Megamax-Modula hat noch einiges zu bieten.
Der Compiler ist mit seinen 5000 Zeilen pro Minute einer der schnellsten seiner Art. Bei Megamax-Modula unterstützt die Shell und das Load-Time-Linking den schnellen Compiler sehr wirkungsvoll. Wenn man Editor, Compiler und die wichtigsten Module resident im Speicher hält, reduziert sich der Editor-Compiler-Zyklus auf wenige Sekunden. Damit macht die Programmentwicklung Spaß. Genauso wünscht man sich das.
Einmal abgesehen von den prinzipiellen Einschränkungen, die Einpasscompiler mit sich bringen, implementiert Megamax-Modula den vollen Modula-Sprachumfang. Die einzige wesentliche Erweiterung betrifft die Rückgabe von strukturierten Variablen als Funktionsresultat. Diese Erweiterung ist sinnvoll, weil sie immer häufiger implementiert wird und auch die kommende Erweiterung des Standards umfassen soll.
Für einige Programmierer bedeutet die Größenbegrenzung der lokalen Variablen auf 32 KByte sicher eine Einschränkung. Abhilfe schafft man, indem man die betreffenden Variablen einfach global definiert. Denn im Gegensatz zu SPC-Modula unterliegt die Größe der globalen Daten bei unserem Testkandidaten nicht der 32-KByte-Marke.
Ein solches Vorgehen ist zwar nicht im Sinne des Erfinders, reicht aber als Provisorium aus. Die sehr guten Turn-Around-Zeiten beeinträchtigen das Stoppen des Compilers, wenn er einen Fehler gefunden hat. Zwar kann man dann direkt in den Editor wechseln. Was hilft das, wenn man eine Menge Fehler im Programm hat und für jeden einzelnen dieser Fehler den Compiler aufrufen muß?
Ein wichtiges Kriterium für die Beurteilung eines Compilers ist der erzeugte Code. Hier schneidet der Compiler nicht sehr gut ab. Wie die Benchmarks zeigen, ist die stackorientierte Auswertung von Ausdrücken nicht das einzige Problem. Auch die Übergabe von Parametern ist ausgesprochen langsam. Die schnellen Bibliotheken kompensieren das zwar teilweise, aber der Unterschied wird in der Praxis doch deutlich.
Ein Beispiel dafür sind Anwendungen wie eigene Speicherverwaltungen oder das Eventhandling in GEM-Applikationen. Die Reaktionen auf Mausklicks sind in Megamax-Modula-Programmen deutlich zäher und hakeliger als gewohnt.
Der integrierte Inline-Assembler geht weit über das hinaus, was Compiler sonst bieten. Besonders interessant ist, daß man auf die Variablen des umgebenden Modula-Programms direkt über ihren Namen zugreift. Man muß sich aber davor hüten, die schlechte Codequalität zu kompensieren, indem man für zeitkritische Anwendungen den Assembler bemüht.
Um die Programmentwicklung optimal zu unterstützen, benutzt Megamax-Modula eine eigene Shell. Die mitgelieferte gehört mit Sicherheit zu den größten ihrer Art — sie umfaßt mehr als 200 KByte. Erklärt, wenn auch bei weitem nicht gerechtfertigt, wird der Umfang durch die umfangreichen Aufgaben, die die Shell in diesem Fall zu erfüllen hat.
Neben dem bereits erwähnten Loader und der Modul- beziehungsweise der Programmverwaltung stellt die Shell umfangreiche Funktionen zur Dateimanipulation bereit. Um dem Programmierer ein vertraute Umgebung zu bieten, empfanden die Entwickler das normale GEM-Desktop weitgehend nach. In manchen Punkten ist das nicht optimal gelungen. Zum einen ist es nicht möglich, mit der Maus mehrere Dateien zu markieren, um sie dann zu kopieren oder zu löschen. Alle Aktionen beziehen sich immer nur auf eine Datei.
Eigenwillige Icon-Kreation
Zum anderen sehen die Laufwerk-Icons in der Shell ganz anders aus, als auf dem GEM-Desktop. Die Laufwerke heißen einfach »Laufwerk A-F«. Es gibt keinen Weg, die Positionen der Icons und der Fenster dauerhaft zu sichern.
Auch wenn viele Kleinigkeiten das Bild trüben, muß man doch sagen, daß die Shell im großen und ganzen ihre Aufgabe gut erfüllt. Das Aufrufen von Editor und Compiler geht flott von der Hand, man kann weitgehend auf die Maus verzichten. Zusätzliche Hilfsmittel wie zum Beispiel die Filter, die es erlauben, in den Dateifenstern zum Beispiel nur Quelldateien anzuzeigen, haben ihren praktischen Nutzen.
Die meiste Zeit verbringt der Programmierer mit Sicherheit im Editor. Deshalb ist es besonders wichtig, daß dieser sowohl zuverlässig als auch flott zu bedienen ist. Der Funktionsumfang spielt eher eine sekundäre Rolle. Wir wollen hier nicht kostbaren Platz für die Beschreibung der Mängel verschwenden, aber einige müssen genannt werden. So wird zum Beispiel eine Zeile mit < Shift F7 > gelöscht. Eine ganze Seite löscht man mit < Shift F8. > Da beide Tasten direkt nebeneinanderliegen, haben wir auf diese Weise schon einige Programmtexte verloren. Es gibt keine Undo-Funktion, und < Shift Undo> beziehungsweise < Control Undo> sind schon wieder Löschfunktionen. Fehlerhafte Eingaben sind fast »vorprogrammiert«.
Eine enorme Einschränkung ist die statische Zeilenlänge von 80 Zeichen. Gerade in Modulall, wo man wegen der besseren Lesbarkeit Schleifenbefehle einrückt, ist das untragbar. Die fünfseitige Anleitung zum Editor besagt: »Die Bedienung ist menügesteuert und selbsterklärend, damit sie den GEM-Konventionen entspricht.«
Die einzige beachtete Konvention im ganzen Programm ist das Vorhandensein von Menüs. Schon mit der Gestaltung derselben hapert es. In der Gestaltungsbibel für GEM-Programme, »Professional GEM«, heißt es eindeutig, daß Menüs sich auf wenige Einträge beschränken sollen. Für das Aussehen des Dateimenüs gibt es ebenfalls vorgeschriebene Konventionen.
Spärlicher Mauskontakt
Das einzige, was man im Editor mit der Maus machen kann, beschränkt sich auf das Anwählen von Menüpunkten. Das Markieren von Blöcken geschieht über Tastatur oder Menü.
In der Anleitung ist von Fenstern die Rede. Wenn man mehrere Texte bearbeiten möchte, muß man zunächst einen zusätzlichen Textpuffer anlegen. Man gibt an, wie viele Zeilen dafür reserviert werden sollen. Ist ein Textpuffer angelegt, dann steht seine Größe unabänderlich fest. Die Texte werden nicht gleichzeitig auf dem Bildschirm angezeigt, man muß zwischen ihnen umschalten. Das konnten schon Texteditoren auf dem C 64 — das nannte man damals nicht Fenstertechnik.
Die Konsequenz daraus: Man muß zum Kaufpreis einen Editor hinzurechnen. »Tempus« fügt sich gut in das System ein und ist vor allem kompakt genug, damit man ihn auch bei 1 MByte RAM im Speicher halten kann.
Wenden wir uns nun wieder erfreulichen Dingen zu. Die Debugging-Fähigkeiten sind besser als üblich. Megamax-Modula kann Programme schrittweise ausführen und gibt dabei vom Programmierer definierte Variableninhalte auf dem Bildschirm aus. Nach einem Laufzeitfehler springt man auf Wunsch direkt in die fehlerhafte Quelltextzeile. Fehlersuche und -korrektur par excellence.
| Art des Benchmarks (Werte in Sek.) | SPC-Modula | Megamax-Modula | Softwave-Modula |
|---|---|---|---|
| IntMath short | 0,895 | 1,160 | 0,65 |
| IntMath long | 2,925 | 2,420 | 2,54 |
| RealMath short | 8,470 | 19,70 | |
| RealMath long | 15,215 | 13.520 | 14,60 |
| TrigLog short | 11,885 | — | nicht gern. |
| TrigLog long | 15,360 | 9,945 | nicht gern. |
| FOR-Schleife | 0,925 | 1,285 | 0,515 |
| LOOP-Schleife | 0,925 | 1,340 | 0,670 |
| REPEAT-Schleife | 0,770 | 1,185 | 0,510 |
| WHILE-Schleife | 0,925 | 1,335 | 0,670 |
| Arrayzugriff | 1,385 | 1,745 | 0,878 |
| Recordzugriff | 1,135 | 1,595 | 0,710 |
| Recordarray | 1,135 | 1,505 | 1,020 |
| Recordarray mit WITH | 0,800 | 1,485 | 0,925 |
| Parameterübergabe | 7,020 | 10,450 | 5,770 |
| Strukturübergabe | 2,245 | 9,450 | 1,865 |
| Conversion | 4,900 | 1,050 | nicht gem. |
| Strings | 8,650 | 2,800 | 1,930 |
Bibliothek in Brockhaus-Qualität
Die mitgelieferten Bibliotheken übersteigen in Qualität und Umfang alles bisher Dagewesene auf dem Atari ST. Neben Modulen zum direkten Zugriff auf das Betriebssystem bekommt man erweiterte GEM-Bibliotheken, die einem sehr viel Arbeit abnehmen.
Wegen ihres enormen Umfangs nur Stichworte zu den Themen der anderen Bibliotheken: Ein-/Ausgabeumlenkung, Kommandozeilenargumente, Datum/Zeit-Behandlung, exzellente Speicherverwaltung, Strings, Dateizugriff, Umlenkung der Textausgabe in GEM-Fenster, Listenverwaltung und so weiter. Auch die Fehlerbehandlung ist einfach nicht zu übertreffen.
Die Bibliotheken sehen nicht nur am Bildschirm gut aus, sondern sind auch wirklich nützlich und praxistauglich. Hier waren echte Profis am Werk.
Für GEM-Programmierer wird der hinreichend bekannte Ressource-Editor von Kuma in einer angepaßten Version mitgeliefert, die auch auf dem Blitter-TOS läuft.
Megamax-Modula bietet eine komfortable Entwicklungsumgebung für alle Programmierer — ob Anfänger oder Profi. Der Editor ist nicht empfehlenswert. Die Turn-Around-Zeiten sind ausgesprochen gut, besonders, wenn man mindestens 1 MByte RAM sowie eine Festplatte zur Verfügung hat.
Wer seine Programme professionell vermarkten möchte, sei vor dem schlechten Code gewarnt. Aber auch der engagierte Hobbyprogrammierer sollte sich davon überzeugen, daß der optimierende Linker tatsächlich lieferbar ist. Mit ihm steht und fällt die Praxistauglichkeit von Megamax-Modula. Der Name Megamax hat sich mit dem Modula-Compiler noch kein Siegel für gute Qualität geschaffen. Die Voraussetzungen dafür sind allerdings gut und Application Systems wird zweifellos alles daransetzen, auch Megamax Modula auf einen Level zu hieven, den man bisher von diesem kleinen, aber feinen Softwarehaus gewohnt war. (hb)
Steckbrief
Produktname: Megamax-Modula II
Preis: 398 Mark
Hersteller: Application Systems Heidelberg
Stärken:
□ gute Turn-Around-Zeiten □ ausgezeichnete Bibliotheken □ gute Debugging-Fähigkeiten □ Quelltext der Shell liegt bei □ großer Lieferumfang □ schnelle Fließkommaarithmetik
Schwächen:
□ schlechter Editor □ mangelnde Codequalität □ fehlender optimierender Linker □ hoher Speicherbedarf des Systems □ Einpass-Compiler
Arnd Beissner