SPC-Modula: Gut integriert ist halb gewonnen

In der Märzausgabe stellten wir fünf Modula-Entwicklungspakete für den Atari ST vor. Inzwischen hat sich ein neuer Kandidat hinzugesellt. Ein vielversprechender, doch lesen Sie selbst.

»SPC-Modula« von Advanced Applications Viczena ist nicht nur ein Compiler. Es ist ein integriertes Entwicklungspaket, bestehend aus Shell, Editor, Make-Utility, Debugger, sehr umfangreichen Bibliotheken, einem sogenannten »Pretty-Printer« und, natürlich, dem Compiler selbst. Als aufmerksamer Leser fragen Sie jetzt zu Recht nach dem Linker. Nun, den gibt es nicht — noch nicht. Doch werfen wir zunächst einen Blick auf die Benutzeroberfläche.

Die einzelnen Bestandteile des Entwicklungssystems sind auf eine ganz besondere Weise integriert. Bei der Implementierung der Atari-Version überlegte man sich, daß es wohl sinnvoll sei, alle Bildschirmein-/ausgaben in Fenster zu leiten. Einerseits sollten alle Teile des SPC-Modula fensterorientiert sein, andererseits, und diese Überlegung macht das Besondere aus, wollte man auch Programmierern diesen Weg offen halten.

Eine weitere Überlegung war, daß ein verallgemeinertes Modula-Fenstersystem nur die Funktionen anbieten sollte, die auf allen Computern, also auch auf rein textorientierten, laufen. Für den Anwendungsprogrammierer hat dies vor allem den Vorteil, daß er seine Programme portabel halten und trotzdem mit einer modernen Benutzeroberfläche versehen kann. Resultat all dieser Überlegungen ist das Fenstersystem SSWiS (Small Systems Windowing System). Es bietet nicht nur verallgemeinerte Fenstersteuerungsfunktionen; einfache Menüfunktionen, vorbereitete Standarddialoge und eine Ereignisbehandlung sind ebenso Bestandteil von SSWiS.

Wertvoll wird ein solches Fenstersystem natürlich nur, wenn es zumindest auf den wichtigsten Computern implementiert ist. Bisher gibt es neben der Atari-Version eine Versados-Implementierung auf einem Motorola 68020-Rechner. Eine OS/2-Version für die Intel-Welt ist in Arbeit, für den Atari ST sind Versionen für OS/9 und RTOS geplant. Die Implementierung auf dem Atari ST setzt auf den GEM-Bibliotheken auf. Besonders raffiniert ist das Problem der begrenzten Anzahl an Fenstern unter GEM gelöst: Am linken Bildschirmrand stapeln sich Textfelder, in denen die Namen der aktiven Fenster stehen.

Die Namen der geöffneten Fenster erscheinen schattiert. Schließt der Benutzer durch Anklicken der Schließbox eines der Fenster, so wandelt sich der Eintrag am linken Bildschirmrand in normale Schrift. Durch Anklicken des entsprechenden Eintrags läßt sich das Fenster wieder öffnen.

Der Clou an der Sache ist, daß das aktive Anwenderprogramm von all diesen Dingen nichts merkt und sich auch nicht darum kümmern muß. Wer schon einmal versucht hat, mit den rohen GEM-Aufrufen fensterorientierte Ein-/Ausgaben zu programmieren, weiß diese Dienste von SSWiS zu schätzen.

Nach diesem Fensterkonzept arbeiten alle Teile von SPC-Modula. Das von manchen geliebte, von vielen gehaßte Standardmodul InOut, das textorientierte Ein-/Ausgabefunktionen bereitstellt, verwendet ein eigenes, Terminal genanntes, Fenster. Da bis auf den Editor alle Teile des Entwicklungssystems über das InOut-Modul ausgeben, sind neben Texten des Anwenderprogramms auch die von Compiler, Shell und Make-Utility im Terminal-Fenster sichtbar. So läßt sich das Terminal-Fenster von SPC-Modula mit einem normalen textorientierten Terminal vergleichen.

Eine enorme Unterstützung bekommt der Benutzer dadurch, daß die virtuelle Größe des Fensters die des Bildschirms bei weitem übersteigt. Auf diese Weise kann man sich ganz einfach noch einmal ansehen, welche Meldungen der Compiler bei seinem vorletzten Lauf ausgegeben hat. Wie praktisch das ist, merkt man in letzter Konsequenz erst dann, wenn man auf einmal ohne Terminalfenster auskommen muß.

Im Gegensatz zu anderen Systemen, bei denen die Shell mit Funktionen geradezu überladen ist, hat sie bei SPC-Modula einen eher beschränkten Aufgabenbereich. Editor, Debugger und Compiler werden durch Tippen eines einzelnen Buchstabens gestartet (E,D,C); andere mit SPC-Modula compilierte Module werden durch Tippen von »R« ausgeführt. Editor und Compiler lassen sich resident in den Hauptspeicher laden, was sich in den Turn-Around-Zeiten positiv bemerkbar macht. Ausgesprochen kundenfreundlich ist, daß der Quelltext der Shell beiliegt. So kann jeder Benutzer die Shell um die Funktionen erweitern, die er für nötig hält.

Alle Einstellungen, die die Shell, der Compiler und der Editor benötigen, sind bei SPC-Modula in den sogenannten Environment-Variablen (näheres zum Thema Environments steht in der Märzausgabe) gespeichert. Veränderungen der Einstellungen merkt sich SPC-Modula automatisch.

Wie eingangs bereits erwähnt, hat SPC-Modula derzeit noch keinen Linker, mit dem sich Programme binden lassen. Wenn Sie diesen Bericht lesen, dürften die registrierten Kunden einen solchen Linker aber im Rahmen des Update-Services erhalten haben. Der hier getesteten Version lag zumindest ein Programm bei, das es erlaubt, alle von einem Programm benötigten Module zu einer Datei zusammenzubinden, die dann ein »Loader« genanntes Programm vom Desktop aus startet.

Aber auch nach seiner Fertigstellung wird der Linker wohl eher ein Schattendasein führen, denn compilierte Module kann die Shell direkt aus führen (im Grunde genommen führt sie nicht die Shell, sondern der sogenannte Loader aus; auch die Shell ist nur ein Modul). Beim Ausführen eines Moduls werden alle erforderlichen Bibliotheks-module in den Hauptspeicher geladen und dort gebunden (Load-Time-Linking). Dies geschieht normalerweise in einer unmerklich kurzen Zeit. Der Vorteil dieses Vorgehens ist, daß während der Entwicklungsphase das zeitaufwendige Binden (Linken) der Module zu einem Programm entfällt.

Auch der Editor stützt sich auf SSWiS, ist also bestens in das Gesamtsystem integriert. Er verwaltet maximal acht Texte in verschiedenen Fenstern. Gerade für Modula-2 ist diese Fähigkeit von großer Wichtigkeit. Wie oft passiert es, daß man sich mal eben die Definition eines anderen Moduls ansehen möchte. Wenn man dazu immer erst den Editor verlassen und neu starten muß, wird das schnell lästig.

Der Editor von SPC-Modula verzichtet bewußt auf alle Features, die man zur Programmentwicklung nur selten benötigt. Er stellt lediglich elementare und damit oft benötigte Funktionen wie Blockoperationen und das Suchen und Ersetzen von Ausdrücken bereit. Auch eine gute Tastaturbelegung, hohe Geschwindigkeit, effizienter Umgang mit dem Speicherplatz und das Springen von Fehler zu Fehler hat man ausgesprochen gut realisiert.

Der Editor hat zwei besondere Fähigkeiten, die ihn zu einem echten Modula-Editor machen. Wenn man die Schlüsselworterkennung aktiviert, braucht man beispielsweise nur »pro« einzugeben, und schon erscheint das Schlüsselwort PROCEDURE an der Cursorposition. Ob man dies praktisch findet, ist freilich Geschmackssache. Wichtiger ist da schon die besondere Behandlung von Tabulatoren. Drückt man die Tabulatortaste, so springt der Cursor direkt unter den nächsten Wortanfang der vorhergehenden Zeile. Selbstverständlich läßt sich der Tabulator auch auf feste Sprungweiten einstellen. Oft benötige Texte ruft man durch Tastendruck ab.

Kritik am Editor ist jedoch in zwei Punkten zu äußern. Zum einen ist das Blockmarkieren mit der Maus nicht gut gelöst. Nach dem Drücken des Mausknopfes am gewünschten Blockanfang erscheint leider keine »Rubberbox«, die den selektierten Bereich kenntlich macht. Einen Anhaltspunkt bekommt der Benutzer nur dadurch, daß der Blockanfang durch ein fettgedrucktes Zeichen dargestellt ist. Erst nach dem Loslassen des Mausknopfes tritt der selektierte Block auf dem Bildschirm hervor. Der zweite Schwachpunkt ist, daß sämtliche Menütexte derzeit k noch in englischer Sprache abgefaßt sind. Kommen wir nun zum Compiler, dem Kernstück eines jeden Entwicklungssystems. Wie auch der Compiler von Jefferson-Modula geht der SPC-Modula-Compiler auf den Einpass-Compiler der ETH Zürich zurück, der vollständig in Modula programmiert wurde. Das Thema Einpass-Compiler scheint momentan ein heißes Eisen zu sein, aus Platzgründen müssen wir aber hier auf eine ausführliche Diskussion verzichten. So sei hier nur gesagt, daß ein Einpass-Compiler ganz bestimmte Einschränkungen mit sich bringt, von denen jeder selbst entscheiden muß, ob er sie tolerieren will oder nicht. Wie immer aber man auch argumentiert, ein Rückschritt ist die Einpass-Technik in jedem Fall.

Die Compilergeschwindigkeit wird mit maximal 5000 Zeilen pro Minute angegeben, die der Compiler aber nur dann erreicht, wenn man mit einer RAM-Disk arbeitet. Bei Benutzung einer Festplatte ist auch bei kleinen Partitions nicht mit mehr als 2500 Zeilen zu rechnen.

Leider weist die Sprachimplementation von SPC-Modula einige Restriktionen auf. Daß einzelne Module eine Codegröße von 32 KByte nicht überschreiten dürfen, ist sicherlich keine gravierende Einschränkung. Weit schlimmer ist jedoch, daß lokale und globale Variablen ebenfalls auf 32 KByte beschränkt sind. Große Arrays sind also nur über den Heap zu realisieren.

Viele Programmierer stört es vermutlich, daß Sets (Mengen) auf 32 Elemente begrenzt sind. Die Herstellerfirma begründet diese Einschränkung damit, daß der kommende Modula-Stan-dard wahrscheinlich nur 32 Elemente pro Set zwingend vorschreiben wird. Programmierer, die das Angebot von größeren Sets nutzen, würden also ihre Programme unportabel machen. Wäre es nicht sinnvoller gewesen, große Sets per Compilerschalter zu erlauben? Module, in denen dieser Schalter eingeschaltet ist, wären dann immerhin ausdrücklich als maschinenabhängig gekennzeichnet.

Die Qualität des erzeugten Codes ist in etwa mit der von TDI-Modula vergleichbar und damit zufriedenstellend, aber eben nichts Besonderes. Die Fließkommaarithmetik (kurze und lange Reals) ist einen Tick schneller als die von TDI. Die genauen Werte entnehmen Sie bitte der Benchmarktabelle.

Bei einem Laufzeitfehler startet der Quellcode-Debugger automatisch, der in mehreren Fenstern den Quelltext des Programms, die Aufrufreihenfolge der Prozeduren und die Variableninhalte anzeigt. Im Quelltext-Fenster erscheint die Programmzeile, in der der Fehler aufgetreten ist, optisch hervorgehoben. Das Datenfenster stellt nicht nur die Inhalte von Variablen einfachen Typs, sondern auch die von strukturierten Variablen dar. Wer einmal mit einem so mächtigen Werkzeug auf Fehlersuche gegangen ist, möchte es nicht mehr missen. Prädikat: besonders wertvoll.

Umfangreiche Bibliotheken sind eine enorme Arbeitserleichterung für den Programmierer. Diese Binsenweisheit trifft freilich nur dann zu, wenn der Funktionsumfang der Bibliotheken ausgewogen und übersichtlich ist. Über den Standard hinaus gehen bei SPC-Modula die Module SSWiS, TextWindows, HFS und Clock. Die Module SSWiS und TextWindows haben wir bereits erläutert.

Das Modul HFS bietet einige unwahrscheinlich praktische Funktionen zur Handhabung von Laufwerken und Pfaden. »Decode« zerlegt einen kompletten GEMDOS-Pfadnamen in Laufwerk, Pfad, Dateiname und Extension; »Encode« setzt aus den einzelnen Komponenten einen vollständigen Pfadnamen zusammen. Mit »ForAllFiles-Do« läßt sich eine vom Programmierer geschriebene Prozedur auf eine bestimmte Menge von Dateien anwenden.

Benchmark in Sekunden	SPC	Megamax	Softwave
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 gemacht
TrigLog long	15,360	9,945	nicht gemacht
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,25	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	1865
Conversion	4,900	1550	nicht gemacht
Strings	8,650	2,800	1,930

»Clock« bietet alle Funktionen zur Handhabung der Systemuhr beziehungsweise des Kalenders. Ähnlich wie im HFS-Modul können komplette Daten (Datum und Uhrzeit) in die einzelnen Komponenten zerlegt und wieder zusammengefügt werden; die Prozedur »Sub« berechnet die Differenz zwischen zwei Zeiten. Der Zeitbegriff schließt hier das Datum mit ein. Selbstverständlich ist voller Zugriff auf GEMDOS, VD1 und AES vorgesehen.

Kurz vor Ende des Tests erreichte uns eine Vorversion eines »Prettyprinters« sowie ein Make-Utility. Der Prettyprinter erlaubt es, Listings formatiert auszudrucken. Er hebt Schlüsselworte hervor und gibt Zeilennummern sowie die jeweilige Schachtelungstiefe aus.

C-Programmierern wird das Make-Utility ein Begriff sein. Dabei handelt es sich um eine komfortable Hilfe bei Projekten, die aus vielen Modulen zusammengesetzt sind. Das Make-Utility ist in der Lage, alle benötigten Module neu zu compilie-ren, soweit dies erforderlich ist. Man muß also nicht ständig die Modulabhängigkeiten im Kopf behalten; es genügt, ein einziges Mal eine Datei zu schreiben.

Das sehr gute Handbuch gibt außer einer Bedienungsanleitung auch eine Einführung in die Sprache Modula-2. Die Definitionen aller Bibliotheksmodule sind im Anhang kommentiert abgedruckt. Ein Index fehlt leider, wird aber in der nächsten Auflage berücksichtigt.

Nun, das Resümee fällt nicht schwer. Das durchdachte Konzept und die gelungene Integration bei soliden, aber leider nur durchschnittlichen Einzelkomponenten sowie die gute Erweiterbarkeit verhelfen SPC-Modula zu einem Platz unter den besten Entwicklungssystemen für den Atari ST. Die Übersichtlichkeit des Pakets und das ausgezeichnete Handbuch halten die Einarbeitungszeit kurz und verhindern Frustrationen. Der vorbildliche Debugger tut ein übriges.

Auch wenn der erzeugte Code keinen Fortschritt darstellt, so ist er doch zumindest nicht schlechter als der des TDI-Compilers, mit dem die meisten Programmierer durchaus zufrieden waren. Wer Stand-alone-Applikationen oder Accessories entwickeln möchte, sollte sich vor der Bestellung noch einmal vergewissern, ob der Linker inzwischen mitgeliefert wird.

Der Preis von 348 Mark ist hinsichtlich der gebotenen Leistung und des guten Services (Anwenderzeitung, ein Jahr lang kostenlose Updates) als günstig zu bezeichnen. (uh)

Vertrieb: Advanced Application Viczena, Spehrlingweg 19,7500 Karlsruhe 31

Arnd Beissner

---

---