Simula ist eine objektorientierte Programmiersprache, die schon in den sechziger Jahren entstand, durch Standardisierung portable Programme ermöglicht und nun als ST-Simula den ATARI ST erreicht hat.
ST-Simula von Simula Team in Dortmund wird auf zwei Disketten mit einer Bedienungsanleitung und einer Sprachreferenz geliefert.
Für die Installation des Simula-Systems muß man etwas Zeit mitbringen. In einem ersten Schritt werden die Dateien der ersten Lieferdiskette in einen beliebigen Ordner kopiert. Die Dateien auf der zweiten Diskette sind mit dem bekannten Komprimierer ZOO gepackt und werden mit zwei Programmaufrufen automatisch auf die Platte kopiert. Dieser Vorgang dauert von Diskette auf Festplatte 45 Minuten - ein Glück, daß eine Installation nur einmalig nötig ist.
Man kann das System natürlich auch mit einem reinen Diskettensystem benutzen - hier werden insgesamt drei doppelseitige Disketten benötigt. Zum Auspacken sind ein zweites Laufwerk oder eine RAM-Disk nötig.
Nach der Installation befinden sich auf der Platte nahezu 225 Dateien in 16 Ordnern, die fast 2 Megabyte belegen. Die Hälfte der Dateien stellen allerdings Beispiele, die im normalen Betrieb natürlich nicht benötigt werden. Zum Betrieb von ST-Simula sollte man aber dennoch mit 2 MB Plattenplatz rechnen.
ST-Simula ist ein “herkömmliches” kommandozeilenorientiertes Entwicklungssystem - im Gegensatz beispielsweise zu Turbo-C. Die Teilprogramme werden per Tastatur und unter Verzicht auf Mausbenutzung von der Guläm-Shell aufgerufen. Das Kernstück des Systems ist der Compiler SIMULA.TTP, der aus einem Simula-Programm einen Assembler-Quellcode erzeugt, und die Laufzeitbibliothek SIMULA.A mit Laufzeitsystem. Der "Rest” des Paketes ist aus vorhandenen Public Domain- und Shareware-Produkten übernommen.
Den Assembler-Code übersetzt der Assembler JAS aus dem SOZOBON-C-Paket in Objektmodule, die vom Linker LD - ebenfalls aus SOZOBON übernommen - mit dem Laufzeitsystem zu ausführbaren Programmen gebunden werden. Alternativ zu JAS und LD können auch MADMAC und ALN aus dem Atari-Entwicklungspaket übernommen werden. Als Shell kommt die Guläm Shell zum Einsatz, die beispielsweise auch im Jefferson-Modula zu finden war.
Den Entwicklungsprozeß unterstützen zwei weitere Werkzeuge aus dem SOZOBON-Paket: MAKE für die automatische Übersetzung voneinander abhängiger Module und AR zur Erstellung und Verwaltung von Archiven, die Bibliotheksmodule schnell und platzsparend bereit stellen.
Die Übernahme von Produkten aus dem Freeware- und Public Domain-Bereich kann durchaus Sinn machen, immerhin handelt es sich bei den genannten Programmen um ausgetestete und zuverlässige Produkte. Damit vermeidet ST-Simula auch das Risiko von Bugs in diesen Systemkomponenten. Auf die Guläm und die SOZOBON-Komponenten soll hier nicht weiter eingegangen werden, wir hatten sie schon in PD-NEWS Nr. 3, respektive PD-NEWS Spezial vorgestellt.
Zur Edierung eines Simula-Programms kann ein beliebiger Editor zum Einsatz kommen, wobei daran zu erinnern ist, daß man aus der Guläm auch GEM-Programme einfach starten kann. Erheblich schneller ist natürlich die Verwendung des in Guläm eingebauten Micro-Emacs.
Die einzelnen Systemprogramme Compiler, Assembler und Linker müssen nicht “von Hand“ nacheinander aufgerufen werden. Simula-Team liefert eine Reihe von Guläm-Scripts - also Batch-Dateien - mit, die die einzelnen Phasen der Programmerstellung automatisch ausführen. So enthält das Script simcl.g die Kommandos zum Aufrufen des Compilers, des Assemblers und des Linkers. Will man das Programm sofort ausführen, benutzt man das Skript simclg.g, wobei das „g” für “Go” steht. Damit werden die Entwicklungsphasen elegant und einfach erlernbar unterstützt.
Für größere Programme, die aus mehreren Modulen bestehen, wird man sich allerdings eher ein Makefile schreiben, das die Abhängigkeiten zwischen den Modulen beschreibt (Beispiele für Makefiles werden mitgeliefert). Der Aufruf von Make führt dann die notwendigen Compilier- und Linkvorgänge aus. Unter den Beispielprogrammen findet sich ein Programm namens SIMDESK, das eine Alternative zur Guläm-Benutzung andeuten soll. SIMDESK entspricht den von anderen Entwicklungssystemen bekannten mausgesteuerten Shells; so findet der Compiler-Aufruf hier mittels Menüauswahl statt.
Die kleine Shell ist allerdings noch im Stadium eines Prototypen - zwar voll funktionstüchtig, aber momentan eher eine Illustration der GEM-Programmierung mit ST-Simula. Nach Angaben des Herstellers soll diese grafische Shell ausgebaut werden, ohne allerdings damit die Guläm abzulösen.
Dem Compiler können verschiedene Kommandos als Optionen für den Übersetzungsvorgang mitgegeben werden. Mit ihnen kann man Zeitmeldungen über die Dauer der einzelnen Übersetzungsphasen erzeugen (Bild 1) oder Warnungen unterdrücken. Weiterhin lassen sich Übersetzungsprotokolle oder Fehler-Listings erzeugen. Für die abschließende Erzeugung eines fertigen Programms dient die Option -h, mit der keine Debugging-Informationen wie Vermerke über Zeilennummern im Quellcode mehr in den erzeugten Objekt-Code aufgenommen werden. Damit werden die Programme natürlich schneller und kürzer.
Zur Korrektur eines Programms aufgrund des Fehler-Listings wird man einen Editor mit mehreren Fenstern benötigen, also beispielsweise Tempur oder eben den Micro-Emacs aus der Guläm.
Ähnlich anderen Entwicklungssystemen wie Pascal oder Modula kennt auch Simula Direktiven, die in den Programmtext eingestreut werden. Die in ST-Simula implementierten Direktiven steuern die Paginierung und Erzeugung von Übersetzungsprotokollen sowie die Aufnahme von Debugging Informationen in den Objekt-Code.
Mit “%INCLUDE < Datei >” läßt sich eine andere Simula-Datei in den Programmtext einlesen, womit man allerdings etwas in Konflikt gerät mit dem Modularisierungsgedanken. Zu beachten ist auch, daß die Direktiven noch nicht standardisiert und damit nicht portabel sind.
Etwas schwach zeigt sich die Fließkomma-Arithmetik. Ein kleiner Test mit der Quadrierung der Quadratwurzel von 2 ergibt nicht den ursprünglichen Wert, sondern 1.9... Turbo-C beispielsweise liefert das korrekte Ergebnis. So klein die Differenz sein mag, jeder Fehler setzt sich in komplizierteren Ausdrücken fort und wächst dabei. Eine Verbesserung der Fließkomma-Routinen hin zu mehr Genauigkeit ist eine dringliche Aufgabe für eine neue Version.
Die komplett gelinkten Programme haben eine erstaunliche Größe. Ein “leeres” Programm ohne jegliche Statements kommt immerhin auf cirka 52 KB. Ursache dafür sind nicht nur die Coroutinenunterstützung und der Garbage-Collector, die auf jeden Fall im Laufzeitsystem stehen müssen. Da die Standardklassen implizit als Präfixe für das Hauptprogramm stehen, ist beispielsweise das File-System immer in jedem Programm vorhanden, selbst wenn es nicht benutzt wird. Auch wenn bei größeren Anwendungen der Platzbedarf des Laufzeitsystems nicht entscheidend ist, wäre eine Optimierung auf Entfernung nicht benutzter Klassen durchaus wünschenswert.
Wir verzichten an dieser Stelle auf Benchmark-Tests. Da kein anderes Simula für den ST vorliegt, wären Simula-Benchmarks nur in Vergleich zu anderen Maschinen zu setzen - hier würde aber eher die Rechenleistung des ST gemessen als die Schnelligkeit des erzeugten Codes. Auch ein Vergleich mit Programmen aus anderen Sprachen würde unfair sein, da beispielsweise die Objektorientiertheit von Simula nicht als Pluspunkt für die Benchmarks verrechnet werden könnte. Nach Auskunft der Entwickler befindet sich die Code-Erzeugung in einer Überarbeitung.
Auch das Laufzeitsystem kann mit Optionen konfiguriert werden, die einfach beim Start eines fertig compilierten Programms als Kommandozeilen-Optionen mitgegeben werden. So würde der Programmaufruf “hello -p“ von Guläm aus das Programm HELLO.TTP ausführen und dabei ein Protokoll über die Speicherverwendung auf dem Bildschirm ausgeben. Mit ”-g” erhält man eine Mitteilung über die Durchführung von Garbage Collections, in denen der dynamisch verwaltete Speicher aufgeräumt wird. Eine Portierung des symbolischen, interaktiven Laufzeitdebuggers des Lund-Simula-Systems ist aber geplant.
Ein Beispiel für solche Protokolle sehen Sie in Bild 2. Da die Speicherverwaltung natürlich Einfluß auf die Laufzeit eines Programms hat, bieten diese Optionen eine gute Möglichkeit, das Laufzeitver halten eines Programms zu überwachen und den Programmtext gegebenenfalls zu optimieren.
ST-Simula umfaßt Bibliotheken, respektive Klassen nach dem Simula-Standard. Hinzukommt ein kompletter Satz der ST-typischen Bibliotheksroutinen für AES, VDI, TOS und Line-A. Sie orientieren sich an den üblichen C-Bindings. Leider sind sie nur als Text-File auf der Diskette dokumentiert, man wird sich für die GEM Programmierung also mit einem Stapel DIN-A4-Ausdrucken herumschlagen müssen. Hier wäre eine Dokumentation im Handbuch wünschenswert.
Auf die AES- und VDI-Bibliotheken soll übrigens ein objektorientierter Aufsatz gesetzt werden, mit dem dann die GEM-Programmierung einfacher werden soll. Diese Schnittstelle liegt momentan allerdings noch nicht komplett vor und ist nicht dokumentiert.
Als Dokumentation werden eine Bedienungsanleitung und eine Sprachreferenz im DIN-A5-Format geliefert. Die Bedienungsanleitung beschreibt den Installationsvorgang, die Benutzung des Systems und den Compiler, den Linker und das Laufzeitsystem sowie die Implementationsdaten und - restriktionen. Die Einbindung in Guläm und die Shell-Skript werden mit Beispielen erläutert. Übrigens werden die Dokumentationen der Public Domain und Shareware-Produkte auf Diskette mitgeliefert.
Die Sprachreferenz ist eine Übersetzung des schwedischen Standards über Simula. Als solcher ist er sicherlich schwerer lesbar als ein Lehrbuch, gibt allerdings zwangsläufig Auskunft über alle Fragen zu Simula. Erfreulicherweise ist der Text auch ab und zu mit Beispielen versehen. Wie oben schon genannt, sind die ST-spezifischen Bibliotheken nicht auf Papier dokumentiert.
Eines wird die Dokumentation sicherlich nicht leisten können: Simula lehren. Wer also ohne Vorkenntnisse mit dem System arbeiten will, kommt um die Anschaffung eines Lehrbuches - von denen der Markt eine Menge bietet - nicht herum.
Ebenso muß der Desktop-Benutzer zunächst den Umgang mit Guläm lernen. An diesem Punkt sind Englischkenntnisse nötig, da die Guläm-Anleitung nicht übersetzt wurde.
ST-Simula kostet den “Normalverbraucher“ DM 198,- zuzüglich Porto und Verpackung. Für den Ausbildungsbereich gibt es einen ermäßigten Preis von DM 148,-, der beispielsweise für Schüler und Studenten, aber auch für Institutionen wie Schulen und Universitäten gilt Ein festes Update-Verfahren besteht noch nicht, allerdings soll bei kleineren Fehlerkorrekturen der Anwender nur die Selbstkosten tragen müssen. Für erweiterte neue Versionen wird allerdings eine höhere Gebühr entstehen. Eine spezielle Version zur Benutzung eines mathematischen Coprozessors ist geplant; sie soll allerdings preislich höher liegen.
Mit ST-Simula ist eine langerprobte und standardisierte objektorientierte Sprache für den ST erschienen. Durch die übermäßige Programmgröße ist sie für die Programmierung kleiner Utilities eher nicht geeignet, und auch die Fließkomma-Arithmetik bleibt zu verbessern.
Wer aber komfortabel ernsthafte Anwendungen, insbesondere aus dem Bereich der Simulation, schreiben will, ist bestens bedient. Durch die Standardisierung lassen sich auch auf einem ST Programme schreiben, die auf andere Systeme portabel sind. Damit wird das System insbesondere für den Universitätsbereich interessant. Schließlich macht es der überaus günstige Preis zu einer wirklichen Alternative zu anderen Entwicklungspaketen.
RT
Bezugsadrcsse:
SIMULA-Team GmbH iG
Postfach 50 01 65
D-4600 Dortmund 50
Simula wurde schon Anfang der sechziger Jahre, ausgehend von ALGOL, entwickelt. Der heute noch gültige Standard entstand 1967; man spricht inzwischen aber nicht mehr von Simula 67, sondern läßt die Jahreszahl einfach weg.
Als Urheber gelten die beiden Norweger Ole-Johan Dahl und Kristen Nygaard. Ihre Arbeit am Norwegian Computing Center in Oslo führte schließlich zu einem Standard, der eine hohe Kompatibilität zwischen verschiedensten Simula-Implementierungen sichert. Obwohl damit schon über zwanzig Jahre alt, enthält Simula verschiedene Konzepte. die heute als hochmodern gelten. Wir wollen ein paar davon herausgreifen.
Simula ist objektorientiert und das schon zu einer Zeit, als sich dieser Begriff noch nicht verbreitet hatte. All das, was heute beispielsweise mit C++ als Offenbarung gefeiert wird, ist in Simula schon vor langen Jahren implementiert worden.
Dazu einige Beispiele aus [1]. Eine Klasse besteht aus einer Menge von Attributen. Dies können Prozeduren oder Variablen sein, wodurch eine Kapselung von Daten und dazugehörigen Prozeduren strukturiert möglich ist. Ein Klassenobjekt wird zur Laufzeit erzeugt, wobei all diese Attribute neu entstehen. Von außen können die Attribute durch eine Referenz angesprochen werden. In unserem Beispiel soll eine Klasse exchange definiert werden, die bei der Erzeugung zwei Parameter erhält und diese danach vertauscht als Attribute anbietet:
class exchange(a,b); real a,b;
begin real c;
c: =a;
a: =b;
b: =c;
end;
ref (exchange) swap;
real d,a;
...
swap new exchange (4.5,3.2);
d:=swap a;
e:=swap b;
...
exchange ist nun eine Klasse, die die Attribute a und b nach außen bereitstellt, swap wird als eine Referenz deklariert, mit der im Programm ein Klassenobjekt vom Typ exchange erzeugt wird, dessen Attribute angesprochen werden können. Mit dem new wird ein Klassenobjekt vom Typ exchange erzeugt. Dabei werden zwei Parameter übergeben, auf die sofort bei der Erzeugung das Programm der Klasse ausgeführt wird. Die drei Statements vertauschen ein fach die zwei übergebenen Werte.
Bei der Erzeugung entsteht eine Referenz auf die neue Klasseninstanz, die in swap abgelegt wird. Man kann sich eine Referenz vielleicht ähnlich einem Zeiger in anderen Programmiersprachen vorstellen, nur daß eine Referenz nicht etwa eine Speicherstelle referiert, sondern alle Attribute einer Klasse.
Die zwei Zuweisungen an d und e greifen nun mit der Referenz swap auf die zwei Klassenattribute a und b zu. Da bei der Erzeugung der Klassenobjekte die zwei Werte vertauscht werden, steht in d dann 3.2 und in e der Wert 4.5. Das Beispiel mag zwar nicht sehr sinnvoll sein und nicht unbedingt Klassen erfordern, zeigt aber doch die Mechanismen des Klassenkonzepts von Simula.
Hat man einige Klassen, die sich vielleicht logisch ähneln und damit teilweise dieselben Attribute enthalten, kann man die gemeinsamen Attribute in einer Klasse zusammenfassen und sie durch Prefixing in die anderen übernehmen. Ein weiteres Beispiel aus [1]:
class vehicle;
begin real length, width, speed;
end;
vehicla class bus;
begin integer seats, passengers;
end
vehicle class truck;
begin real load, capacity; end;
Hier enthält die Klasse vehicle Attribute, die jede Art von Fahrzeugen hat, nämlich Länge, Breite und Geschwindigkeit. Die Klassen bus und truck sind Fahrzeuge, übernehmen durch Prefixing die Attribute von vehicle und fügen eigene Objekte hinzu. So sind in der Klasse bus zusätzlich die Attribute Sitze und Passagiere vorhanden.
Wir können das Beispiel so erweitern, daß Listen von verschiedenen Fahrzeugen verwaltet werden können. Für Listen ist standardmäßig die Kontextklasse Simset mit ihren Klassen head und link zuständig. Wir prefixen vehicle einfach mit link und können nun alle Listen-Operationen mit allen Fahrzeugen durchführen:
link class vehicle;
...
ref (head) list;
list := new head;
new bus.into(list);
new truck.into(list);
new bus.int(list);
list wird als Referenz vom Typ head deklariert. head ist praktisch der Anker einer Liste. Nach der Erzeugung einer Liste mit new können die verschiedenen Fahrzeuge mit into in die Liste eingefügt werden. Da die Klasse link Präfix von vehicle war, gibt es in der Klasse bus und in truck das Objekt into.
Die zweite Besonderheit an der Sprache Simula ist ihre namensgebende Eignung für Simulationen. Dazu stellt die Standardklasse Simulation die nötigen Routinen bereit.
Die Aktivitäten der Simulation werden als Prozesse dargestellt. Diese können zu bestimmten Zeiten aktiviert und ausgeführt werden. Dabei werden sie entlang der simulierten Zeitachse entsprechend dem Simulationsmodell aktiviert.
Für die Aktivierung eines Prozesses sorgen hauptsächlich die activate-Statements. activate p at 100.0 aktiviert den Prozess zum Zeitpunkt 100 auf der simulierten Zeitachse. Mit activate p delay 100.0 würde p 100 Zeiteinheiten nach der aktuellen simulierten Zeit aktiviert werden.
Aufgrund dieser Statements ist bei der Ausführung eine Schedule-Liste entstanden, aufgrund der die einzelnen Prozesse zur Ausführung kommen. Damit beherrscht Simula ein Coroutinen-Konzept, das von der Simulation-Klasse zu einem Simulations-Modell mit einer Zeitachse erweitert wird. Diese Beschreibung ist natürlich verkürzend, und für ernsthafte Anwendungen ist eine gewisse Kenntnis von Simulationsmodellen nötig.
Engagierte Anwender haben sich in einer Simula-Benutzergruppe zusammengeschlossen, die vierteljährlich einen SIMULA-Newsletter herausgibt:
Association of SIMULA Users (ASU)
Ron Kerr
Computing Lahoratory
University of Newcastle upon Tyne
GB-Newcastle upon Type NE1-7RU
Großbritannien
[1] P.R.Hills: An Introduction to Simulation Using Simula Norwegian Computing Center, Oslo. 1973.