computerwoche.de

Archiv

Fallbeispiel zur Auswahl von Pascal als Computersprache:

CA-Earl auf Kundenwunsch neu geschrieben

08.02.1980

FERNEY-VOLTAIRE (pi) - In welcher Computersprache Software erstellt werden soll - mit dieser Frage beschäftigt sich Russ Artzt Vizepräsident der französischen Computer Associates S.A., an einem konkreten Beispiel. Er erläutert, weshalb sich Computer Associates bei einer notwendigen Neufassung des Listenprogrammgenerators CA-Earl Pascal entschieden hat.

Unser Problem war, daß das im Jahr 1971 geschriebene Paket CA-Earl in seiner Auslegung zu beschränkt war, um den vielfältiger werdenden Programmieraufgaben noch gerecht zu werden. Obwohl immer wieder verbessert, war es doch nicht möglich, den ursprünglichen Beschränkungen ganz auszuweichen.

Trotzdem wird, wie Benutzerumfragen ergaben, ein zunehmender Anteil an Programmieraufgaben mit Hilfe von CA-Earl bewältigt, anstatt dafür höhere Programmiersprachen wie Cobol oder PL/1 zu verwenden. Das gleiche gilt sicher auch für andere Listenprogrammgeneratoren.

Kriterien für den Entwurf

Als ersten Schritt galt es, die Spezifikation für den Entwurf festzulegen. Wir erhielten von den Anwendern eine Wunschliste, nach der das neue CA-Earl eine höhere Programmiersprache sein sollte, die für die Mehrzahl der täglichen Programmieraufgaben ausreicht: Codierung und Maschinenzeit sollten auf ein Zehntel dessen reduziert werden, was für Cobol und PL/1 erforderlich ist; die Möglichkeiten zur Datenverarbeitung sollten erheblich verbessert werden und vieles andere mehr. Außerdem sollte die neue Version genügend erweiterbar sein damit im Lauf der Jahre zusätzliche Entwicklungen berücksichtigt werden könnten. So blieb nur die Wahl, das Paket völlig neu zu schreiben.

Als weitere Bedingungen hatten wir festgelegt, daß die neue Version im Betrieb mindestens so schnell sein sollte wie die vorhergehende und so einfach wie möglich zwischen IBM-Computern und denen anderer Hersteller "transportierbar" bleiben müsse. Schließlich stellte sich die Frage der zu verwendenden Programmiersprache. Eines der Probleme bei der Entwicklung von Systemsoftware, im Gegensatz zu großen Anwendungsprogrammen, ist die zu erzielende maximale Wirtschaftlichkeit bei der Benutzung der Systemelemente. Bis jetzt hatte diese Bedingung die Verwendung von Assembler erfordert. Da jeder Hardware-Hersteller jedoch seinen Computern ihre eigene Struktur gibt und somit einen eigenen Assembler benötigt, erschien die Realisierung der Portabilität von CA-Earl recht problematisch.

Wir entschlossen uns zu einer Bewertung aller Sprachen, die uns zur Verfügung standen: Assembler, Cobol, PL/1 PL/370 und Pascal. Die wesentlichen Bedingungen waren Zuverlässigkeit, Wirtschaftlichkeit im Einsatz der Systemelemente, gutes Kosten-/Leistungsverhältnis in Bezug auf die Codierzeit und problemlose Portabilität.

Assembler wurde ausgeschlossen, denn gerade seine Stärke hinsichtlich der Präzision; mit der sich diese Sprache verwenden läßt, stellte sich als schwache Seite heraus, wenn gewisse Grenzen an Zeit und Aufwand für die Entwicklung berücksichtigt werden. Cobol und PL/1 wurden eliminiert, weil das Paket dadurch zu umfangreich geworden wäre und zudem an Leistungsfähigkeit eingebüßt hätte. PL/370 und Pascal wurden recht genau untersucht. Es wurden mit jeder der beiden Sprachen Musterprogramme geschrieben, um anschließend die Schwierigkeit des Programmierens und die Leistungsfähigkeit des generierten Codes vergleichen zu können. Pascal ergab eine hohe Produktivität bei der Programmierung - zumindest das Vierfache im Vergleich zu Assembler. PL/370 dagegen erschien eher dem BAL-Assembler von lBM verwandt zu sein und erschwerte erheblich die Portabilität. Weitere Untersuchungen von Pascal ergaben folgendes:

1. Pascal erlaubt während des Kompilierens reichliche Logik-Tests. So lassen sich etwa definierten Feldern und Adressen Bereichswerte zurordnen, die das Pascal-System dann zur Gültigkeitsprüfung verwendet. Der Testvorgang ist also schon wesentlich weiter fortgeschritten, sobald der Compiler einen "fehlerfreien" Code generiert. Auch verkürzt der Run-Time-Checker die aufzuwendende Testzeit.

2. Im Vergleich zu Assembler benötigt Pascal um mindestens einen Faktor 10 weniger Generierung von Quellencode.

3. Mit Hilfe der Gruppe von Pascal-Benutzern in den USA wurden alle verfügbaren Pascal-Compiler für die IBM 360/370 bewertet. Der Compiler existierte sowohl in der VM/CMS-Version als auch in der OS-Version für Stapelbetrieb. Nun ist aber VM/CMS zusammen mit IDOS/VS das am meisten benutzte Betriebssystem im /370-Entwicklungszentrum von Computer Associates. Mit etwas zusätzlichem Aufwand wurde der Compiler ebenfalls für DOS-Anwendungen brauchbar gemacht.

4. Für die von uns geplante "Top-Down"-Auslegung ist Pascal ebenfalls geeignet.

5. Der von uns benutzte Pascal-Compiler (vom Stanford Accelerator Centre) gestattet es, einen Code für die Bearbeitung entweder direkt von der Kompilierung zu erhalten, oder vom Assembler-Quellencode. Die letztere Möglichkeit stellte sich für unser Projekt als besonders geeignet heraus.

Portabilität bedingt erreichbar

Wegen der "interpretierenden" Art des Pascal-Compilers und des ähnlichen Konzepts, das deshalb bei der Entwicklung des neuen CA-Earl zu befolgen war stellte sich der generierte Code als etwas weniger leistungsfähig heraus als vergleichsweise Assembler. Wir vertraten jedoch die Ansicht, daß die mit Pascal weit flexiblere Möglichkeit zur Weiterentwicklung sowie die zahlreichen Verbesserungen der neuen Version diesen leichten potentiellen Nachteil reichlich wettmachen würden.

Neben den Vorzügen, die sich uns bei der Entwicklung boten, gab es einige weniger vorteilhafte Aspekte, die, zusätzliche Anstrengungen erforderten: So ist ein Pascal beispielsweise nicht zur Erzeugung von Overlay-Moduln geeignet, womit unsere neue Version in einer 64-K-Partition in einer optimalen Stufe laufen könnte. Wir waren gezwungen die Betriebsart von Pascal zu ändern, um die geforderte Overlay-Struktur zu realisieren.

Es stellte sich ebenfalls heraus, daß dem von uns gewählten Pascal-Compiler eine Anzahl von I/O-Möglichkeiten fehlte. Deshalb ergänzten wir mit Assembler alle Routinen, die sowohl für das Kompilieren als auch für die Echtzeitverarbeitung mit dem Paket erforderlich waren. Einige Probleme ergaben sich auch durch die Abhängigkeit von der Anlage selbst. So ließ sich zum Beispiel eine Reihe von Fragen, die mit dem physikalischen Ein-/Ausgabesystem und dem Management des Kernspeichers spezieIl einer IBM-Umgebung zu tun haben, nicht zufriedenstellend lösen. Wir griffen deshalb auch hier auf Assembler zurück.

Schließlich gibt Pascal keinen korrigierbaren ladefähigen Code. Da es aber Assembler-Coder in der Quellenstufe generiert, konnten wir den generierten Quellencode modifizieren und somit dieses Problem beseitigen.

Es läßt sich zusammenfassend sagen daß die für das 'Paket ursprünglich gesetzten Ziele mit Erfolg erreicht wurden selbst wenn das Paket nicht ganz portabel ist (es ist es zu mindestens 80 Prozent).