Table Of ContentInformatik-Fachberichte
Herausgegeben von W.Brauer
im Auftrag der Gesellschaft rur Informatik (GI)
25
Programmiersprachen und
Programmentwicklung
6. Fachtagung des Fachausschusses
Programmiersprachen der GI
Darmstadt, 11.-12. März 1980
Herausgegeben von H.-J. Hoffmann
Springer-Verlag
Berlin Heidelberg New York 1980
Herausgeber
Prof. Dr. Hans -Jürgen Hoffmann
Fachgebiet Programmiersprachen
und Übersetzer
Institut für Praktische Informatik
Fachbereich 20
Technische Hochschule Darmstadt
Steubenplatz 12
6100 Darmstadt
AMS Subject Classifications (1970): 68 A 05
CR Subject Classifications (1974): 4., 4.1, 4.12, 4.2, 4.22, 4.9, 5.23
ISBN-13:978-3-540-09937- 6 e-ISBN-13:978-3-642-67600-0
001: 10 .1007/978-3-642-67600-0
CIP-Kurztitelaufnahme der Deutschen Bibliothek
Programmiersprachen und Programmentwicklung:
6. Fachtagung d. Fachausschusses Programmiersprachen d. GI, Darmstadt,
11. -12. März 1980 I hrsg. von H.-J. Hoffmann. - Berlin, Heidelberg, New York:
Springer, 1980.
(Informatik-Fachberichte; 25)
NE: Hoffmann, Hans-Jürgen [Hrsg.]; Gesellschaft für Informatik I Fachausschuss
Programmiersprachen
This work is subject to copyright. All rights are reserved, whether the whoJe or part 01 the
material is concerned, specilically those 01 translation, reprinting, re-use 01 illustrations,
broadcasting, reproduction by photocopying machine or similar means, and storage in
data banks.
Further, storage or utilization 01 the described programms on date processing installations is
forbidden without the written permission of the author.
Under § 54 of the German Copyright Law where copies are made for other than private use,
a fee is payable to the publisher, the amount of the fee to be determined by agreement
with the publisher.
~) by Springer-Verlag Berlin . Heidelberg 1980
2145/3140 -5 4 3 2 1 0
VORWORT
Die Fachtagungen, die der Fachausschuß 2 der Gesellschaft für
PROGRAMMIERSPRACH~N
Informatik*) seit 1971 regelmäßig, nunmehr zum sechsten Mal, veranstaltet und in Ta
gungsbänden dokumentiert, geben Zeugnis von dem jeweiligen Selbst-Verständnis des
Faches PROGRAMMIERSPRACHEN, zumindest aus der Sicht einiger seiner Repräsentanten
und der Vortragenden. Die 6. Fachtagung, die am 11. und 12. März 1980 in Darmstadt
stattfindet, spielt darin sicherlich keine Sonderrolle. Es wurde diesmal eine breitere
Thematik gewählt, wie es aus der Tagungsbezeichnung hervorgeht, nämlich
PROGRAMMIERSPRACHEN UND PROGRAMMENTWICKLUNG.
Jedenfalls wird damit zum Ausdruck gebracht, daß Programmiersprachen nicht nur eine
Zielsetzung in sich haben, d.h. einem Selbstzweck unterworfen sind, sondern zu einem
weiteren Zweck, der Programmentwicklung, in Beziehung treten, in Beziehung treten
müssen. Dieses verbreiterte Selbst-Verständnis hat sich - bedauerlicherweise - im
Tagungsprogramm und als Folge davon im Tagungsband nicht übermäßig deutlich ausge
wirkt. Die Veranstalter legen allerdings zum Zeitpunkt der Drucklegung die (berech
tigte) Hoffnung, daß in der vorgesehenen Diskussion über "Software Engineering -
Programmiersprachen, Programmentwicklung -" zu der breiteren Thematik einige beach
tenswerte Aussagen kommen. Im Tagungsband, der den Tagungsteilnehmern zu Beginn der
Tagung ausgehändigt wird, läßt sich eine solche Diskussion noch nicht einfangen;
ihre Auswirkungen zeigen sich, hoffentlich, an anderer Stelle.
In der Bitte um Vortragsmeldung hatte der Fachausschuß die Thematik der Fachtagung
in die folgenden Worte gefaßt:
Es soll berichtet werden über neue Konzepte in Programmiersprachen, über die
Lösung besonderer Probleme bei der Implementierung von Programmiersprachen
insbesondere bei der semantischen Analyse, Code-Erzeugung und Laufzeitunter
stützung, über den Einsatz von Programmiersprachen z.B. zur Systemimplemen
tierung, bei Programmgeneratoren, in Systemen, die die Programmspezifikation
und Programmentwi ckl ung unterstützen, u. ä. sowie über neue Erkentni sse und
fundierte Wertungen zur Programmiertechnik. Neben diesen Schwerpunkten sind
auch Meldungen zu allgemein interessierenden Themen aus dem genannten Gebiet
erwünscht sowie Referate zur Analyse der Programmiersprachen-"Landschaft"
willkommen.
*) K. Alber (TU Braunschweig), C. Haenel (Siemens, München), H.-J. Hoffmann
(TH Darmstadt), G. Mußtopf (SCS, Hamburg), H.-J. Schneider (Univ. Erlangen
Nürnberg), G. Seegmüller (Univ. München) und C. v. Urach (Daimler-Benz,
Stuttgart).
IV
Auf die Bitte am Vortragsmeldung gingen 34 Beiträge ein. In einer breiten, sorgfäl
tigen Begutachtung wurden daraus 13 Beiträge ausgewählt und zur Tagung angenommen.
Allen Beitragenden, auch denjenigen, deren Beitrag nicht angenommen wurde, sei an
dieser Stelle für die aufgewendete Mühe gedankt. Darüberhinaus wurden noch vier für
ihre Arbeiten bekannte Wissenschaftler aufgefordert, in eingeladenen Vorträgen über
ihr Arbeitsgebiet zu berichten. Auch hier sei der Dank dafür ausgesprochen, daß sie
die Einladung annahmen und in verhältnismäßig kurzer Zeit auch einen schriftlichen
Beitrag fertigstellten.
Es mag vielleicht auffallen, daß zwei Teilgebiete aus der Thematik Programmierspra
chen und Programmentwicklung, in Anbetracht ihrer Aktualität jedenfalls, unterreprä
sentiert sind: Die beiden Fachgruppen des Fachausschußes, nämlich die Fachgruppe
"Interaktives Programmieren" und die Fachgruppe "Compiler-Compiler" stehen auf eige
nen Füßen und bedürfen für die Darstellung ihrer Arbeit nicht einen Teil einer um
fassenderen Fachtagung. Trotzdem war es von der Veranstaltern gerne gesehen, daß die
Fachgruppe "Interaktives Programmieren" am 10. März 1980 am gleichen Tagungsort ihr
diesjähriges Treffen veranstaltet; Im Heft 4 der Notizen für Interaktives Program
mieren werden die Beiträge zu diesem Treffen veröffentlicht.
Allen, die zum Zustandekommen und zur Durchführung der Tagung beigetragen haben, sei
an dieser Stelle gedankt. Man sehe es mir nach, daß ich keine Namen aufzähle. Der
Dank ist darum nicht geringer. Die Tagungsteilnehmer finden in den Tagungsunterlagen
eine Zusammenstellung von Spendern, denen an dieser Stelle - vorab - nun pauschal
gedankt sei.
Darmstadt, Dezember 1979 Hans-Jürgen Hoffmann.
INHALTSVERZEICHNIS
Vergleich einiger Konzepte moderner Echtzeitsprachen
U. Ammann
- eingeladener Vortrag -
The "Design by Objectives" Method for Controll ing Maintainabil ity:
A Quantitative Approach for Software ............................... 19
T. Gi 1b
- eingeladener Vortrag -
An Incremental Compiler as Component of a System for Software
Generation 29
M. Nagl
- eingeladener Vortrag -
Recent History and the Furture of COBOL 45
D. F. Nelson
- eingeladener Vortrag -
A Critical Review of PASCAL Based on a Formal Storage Model ............. 57
B. Austermühl, W. Henhapl
Exception Handling with Multi-Exit Statements ........................... 71
R.-J. Back
A Methodology for Message Oriented Programming .......................... 83
P.R.F. Cunha, C.J. de Lucena, T.S.E. Maibaum
LIS as Object Code for an ADA-O-Compiler 95
M. Dausmann, G. Perseh, G. Winterstein
Design Rationale for the Interactive Programming Language CSSA 111
H.L. Fischer, P. Raulefs
OPTRAN, a Language for the Specification of Program Transformations ..... 125
I. Glasner, U. Möncke, R. Wilhelm
VI
Some Considerations for an Extension of PL 360 ...........•....•......... 143
F. Hertweck, I. Precht
Eigenschaften von Programmiersprachen - definiert durch attributierte
Grammatiken 157
U. Kastens
Das Konzept des Programmiersprachenkerns von TA3
- Darstellung eines deskriptiv orientierten Ansatzes - ............. 175
G. Knorz
Ein Praktikum im Obersetzerentwurf: Struktur und Erfahrungen ...•........ 189
H.H. Kron, R. Lutze
A Basis for Secure Systems Implementation Languages ........•..•..•...... 199
K.-P. Löhr
Benutzergerechtes Editieren - eine neue Sichtweise von Problemlösen
mit DV-Systemen .•.•........•......•.•.................••......•.... 211
H. Oberquelle
Sequentialisierung von Parallelen Prozessen ............................. 221
J. Schauer
VERGLEICH EINIGER KONZEPTE MODERNER ECHTZEITSPRACHEN
Urs Ammann
Contraves AG, Abt. EMGC
Postfach
CH-81il52 Zuerich
Switzerland
ZUSAMMENFASSUNG: Einleitend wird den Wurzeln der Multiprogrammierung
in den klassischen Programmiersprachen der zweiten Generation - PL/I,
Simula und Algol 68 - kurz nachgegangen. Der Hauptteil konzentriert
sich auf einige markante Sprachelemente interessanter Sprachen wie
Ada, Cuncurrent Pascal, Modula und PEARL und es werden einige
Bemerkungen zur Implementierung verschiedener dieser Konzepte gemacht.
ABSTRACT: In the introductory part we follow the roots of
multiprogramming in the classical second generation languages PL/I,
Simula and Algol 68. In the main part we concentrate on some salient
features of interesting languages such as Ada, Concurrent Pascal,
Modula and PEARL and comment on the implementation of several of these
concepts.
Inhalt
1. Einleitung
2. Die klassischen Sprachen der zweiten Generation
3. Moderne Systemimplementationssprachen
3.1 Concurrent Pascal
3.2 Modula
3.3 PEARL
3.4 Ada
4. Schlussbemerkung
Referenzen
2
1. Einleitung
Mit der rasanten Zunahme des Einsatzes von Mini- und Mikro-Rechnern im
Anwendungsbereich Prozesskontrolle, z. B. zur Steuerung und Regelung
von technischen Prozessen, ist das Interesse an den sogenannten
Echtzeitsprachen in den letzten Jahren sprunghaft gestiegen. Der
hauptsaechlichste Grund dafuer ist, dass man mit der konventionellen,
in diesem Einsatzbereich noch immer dominierenden Assemblerprogram
mierung an verschiedene Grenzen stoesst. So geben etwa die duerftige
Produktivitaet der Maschinenprogrammierer, die nicht mehr
bewaeltigbare Komplexitaet neuer Anwendungen, die mangelnde Sicherheit
und Modularitaet der entwickelten System-Software und die damit
einhergehende Kostenexplosion zu wachsender Besorgnis Anlass. Diesen
Problemen wird nun in zunehmendem Mass durch den Einsatz von
Echtzeitsprachen Herr zu werden versucht. Die schwerwiegendsten
Hemmschuhe bei dieser begruessenswerten Entwicklung sind wohl der
Bedarf an qualitativ einwandfreier zusaetzlicher Infrastruktur
Software (Compiler), Effizienzeinbussen in den uebersetzten Programmen
und nicht zuletzt das traege Verhaften im Hergebrachten.
Moderne Echtzeitsprachen sind im landlaeufigen Sinn hoehere
Programmiersprachen mit einigen zusaetzlichen Sprachelementen, um die
Anforderungen der Systemprogrammierung im allgemeinen und der
Echtzeitprogrammierung im speziellen abzudecken. Im Idealfall lehnen
sie sich im algorithmischen Teil stark an bestehende Sprachen wie
Algol, Pascal oder PL/I an und verfuegen ueber ein strenges
Typenkonzept, reiche Datenstrukturierungsmoeglichkeiten sowie einen
Satz von bewaeh~ten Anweisungen zur Steuerung des Berechnungsflusses.
Um den Beduerfnissen der Systemprogrammierung gerecht zu werden,
sollten sie ein Konzept zur Modularisierung von Programmen (wie etwa
der Modul in Modula [Wir77] oder das Package in Ada [DOD79])
enthalten. Dazu muss die Moeglichkeit zum Ausdruecken von (pseudo-)
parallelen Berechnungen wie etwa die Task (in Ada oder PEARL [KFK77])
oder den Prozess (in Modula) gegeben sein. Diese nebenlaeufigen
Berechnungen muessen synchronisiert werden koennen (etwa durch
Semaphore wie in Algol68 [Wij69] oder durch Signale wie in Modula) und
es braucht ein Sprachelement zum gegenseitigen Ausschluss
konkurrierender Prozesse beim Zugriff auf gemeinsame Daten (Monitor in
Concurrent Pascal [Han75], Interface-Modul in Modula, Rendezvous in
Ada). Daneben sind meist auch Sprachelemente vorhanden, welche die
maschinennahe Programmierung erlauben, wie etwa die Einflussnahme auf
die Datenrepraesentation und die Adressen von Objekten, die
Programmierung von Peripheriegeraeten und damit die Integrierung von
Interrupts und des damit zusammenhaengenden Prioritaets-Scheduling ins
Benuetzerprogramm. Um schliesslich den Beduerfnissen der Echtzeit
programmierung gerecht zu werden, muss eine mit der Umwelt
synchronisierte Uhr vorhanden sein und es muessen Sprachelemente
existieren, welche die Einplanung von Berechnungen mit Bezug auf die
Uhrzeit erlauben.
Grundsaetzlich lassen sich die EChtzeitsprachen in zwei Klassen
einteilen. Die erste Klasse besteht aus jenen Sprachen, welche die
Beduerfnisse der Multiprogrammierung und insbesondere der Echtzeit-
programmierung (fast) ausschi iessl ich mit Aufrufen von
Standardprozeduren oder weit schlimmer mit eingestreuten
Assemblersequenzen abdecken, also (fast) keine auf diesen spezifischen
Anwendungsbereich zugeschnittenen Sprachelemente enthalten. Zu dieser
Klasse gehoeren Sprachen wie CORAL66 [HMS070], RTL/2 [ßar76], sowie
verschiedene Erweiterungen von FORTRAN fuer Echtzeitanwendungen. Vom
heutigen Stand der Sprachentwicklung muss dieser Ansatz als veraltet
bezeichnet werden. Wenn er auch einige wenige vorzuege wie
3
explizitere Kontrolle und erhoehte Effizienz der Objektprogramme
aufzuweisen hat, so vermag er doch konzeptionell nicht zu befriedigen
und bedeutet in jedem Fall Verlust an Sicherheit, Modularitaet und
Uebertragbarkeit.
Zur zweiten Klasse gehoeren jene Sprachen, die den Beduerfnissen der
Multiprogrammierung durch geeignete Sprachkonstrukte nachkommen. Zu
ihnen gehoeren weniger bekannte Vertreter wie PROCOL [PR070], HALlS
[HAL75] und PORTAL [Lie79], von denen in der Folge nicht oder nur am
Rande die Rede sein wird, und prominentere Vertreter wie Ada [00079],
Concurrent Pascal [Han75], Modula [Wir77] und PEARL [KFK77]. Ihnen
wird der Hauptteil des Vortrages gewidmet sein.
Zunaechst soll jedoch kurz den Urspruengen der Multiprogrammierung in
der Mitte der 60er Jahre entstandenen Sprachen der zweiten Generation
nachgegangen werden.
2. Die klassischen Sprachen der zweiten Generation
Es ist fuer das Verstaendnis der Sprachelemente moderner
Echtzeitsprachen recht nuetzlich, kurz auf die Grundlagen der
Multiprogrammierung in den klassischen Sprachen Algol 68 [Wij69], PLII
und Simula [Dah66] einzugehen.
Die erste, wenn auch keineswegs verwunderliche Feststellung, die dabei
gemacht werden kann, ist die, dass sich die grundsaetzlich unter
schiedlichen Sprachphilosophien auch in den Mitteln zur Beschreibung
von parallelen Berechnungen wiederspiegeln: in Algol68 Beschraenkung
auf das absolut Notwendige, in PLII eine Fuelle von Sprachelementen
und in Simula die Rueckfuehrung auch dieser Beduerfnisse auf das
zentrale Sprachelement, die Klasse.
Algol68, das sich ja durch wenige "orthogonale" Konzepte auszeichnet,
die jedoch beliebig miteinander kombiniert zu elner maechtigen
Vielfalt werden, beschraenkt sich auf zwei in ihrer Schlichtheit nicht
mehr zu uebertreffende Sprachelemente. Es ist dies einerseits der
Datentyp SEMA mit den auf Sema-Variablen anwendbaren monadischen
Operatoren I, ~ und t (Initialisierung, P- und V-Operation).
Andererseits existiert eine Parallel-Klausel, in der nebenlaeufige
Berechnungen voneinander durch Kommata getrennt und durch Klammern zu
einer Einheit zusammengefasst werden koennen, der zur Kennzeichnung
das Symbol PAR vorangestellt wird. Damit lassen sich Prozesse kreieren
und starten, deren Synchronisation durch n-wertige Semaphore
ermoeglicht wird. Zusaetzliche Sprachelemente, etwa zum garantierten
gegenseitigen Ausschluss beim Zugriff mehrerer Prozesse auf deren
gemeinsame Daten gibt es nicht, kann jedoch mit Semaphoren explizit
ausprogrammiert werden (vergi. unten).
Ein kleines Beispiel aus dem Algol68-Report moege den Gebrauch von
Parallel-Klauseln und Semaphoren illustrieren. Es implementiert eine
Menge von Produzenten, die Seiten produzieren, welche sie in einem
gemeinsamen Magazin abliefern. Hier werden sie von Konsumenten
abgeholt und konsumiert.
4
bsgin int nmb magazins sZots. nmb producers. nmb consumers;
rsad «nmb magazine sLots. nmb producers. nmb consumers));
[l : nmb producers] tUe infUs. [l : nmb consumers] [i~e outfUe;
~ i to nmb producers do open (infi~e [i~. inchanneL :r.]);
~ inchanneL and outchanneL are def~ned ~n a surround~ng range 9
for i to nmb consumers do open (outfiLe (i]. outchanneL (i]);
=
~ ~ [l : 60. 1 : 132] chazo; •
[l : nmb magazine sLots] !:!!i. ~ maganne;
int 9 pointers of a cycLic magazine 9 index := 1. exdex := 1;
sema fuLL sLots = / 0. [ree sLots = / nmb magazine sLots.
--rn buffer busy = / 1. out buffer busy = / 1;
proc par caLL = (proc° (int) P. int n) 9 caLZs n incarnations of p in
paralleZ 9 : (n > I PB!. (p TriJ. par call (P. n - 1)));
proc producer = (i!;! i) : do (~~page; get (infUe(i]. page);
+ free sLots; + ~n buffer busy;
magazine (index] := page; index t::= nmb magazine sZots +:= 1;
t fuLZ sZots; t in buffer busy;
proc consumer = (int i) : do (~page;
+ fuZZ sZots; + out buffer busy;
page := magazine [exdex]; exdex t::= nmb magazine sZots +:= 1;
t [ree sZots; t out buffer busy; put (outfiZe (i]. page));
PB!. (par call (producer. nmb producers).
par calL (consumer. nmb consumers))
end
Das Beispiel zeigt schoen zwei in ihrer Natur verschiedene
Synchronisationsbeduerfnisse:
Wenn das Magazin voll resp. leer ist, muessen die Produzenten
resp. Konsumenten, die eine Seite abliefern, resp. holen wollen,
warten (Semaphore full slots, free slots).
Wenn ein Produzent resp. Konsument die kritischen Daten des
Magazins manipuliert, so duerfen die andern Produzenten resp.
Konsumenten keinen Zugriff haben (Semaphore in buffer busy, out
buffer busy). Dagegen koennen ohne weiteres gleichzeitig ein
Produzent und ein Konsument am Magazin operieren.
Anders als in Algol68, welches als systematische Verallgemeinerung von
Algol60 verstanden werden muss, wurde in PL!I versucht, die als
erfolgreich eingestuften Sprachelemente von Algol60, COBOL, FORTRAN
und LISP zu vereinen. Die dabei verbliebenen Luecken wurden durch eine
ganze Reihe von neuen Sprachkonstrukten abzudecken versucht.
Ein grundsaetzlich neues Element ist die Task, welche eine in sich
sequentielle Berechnung definiert, die jedoch parallel zu anderen
Berechnungen geschehen kann. Kreiert wird eine Task ueber die normale
CALL-Anweisung mit der auch Prozeduren aufgerufen werden, wobei die
Existenz optioneller Attribute die Task-Kreation vom simplen
Prozeduraufruf unterscheidet:
CALL p(al, ... ,an) ,TASK(task name) ,EVENT(event name) ,PRIORITY(n):
'-----y---I .. \I' J
normaler Proz.auf- optionelle Attribute, welche die Ausfuehrung
ruf mit akt. Para- von p nebenlaeufig machen
metern al ... an
MLt dem TASK-Attribut kann der Task zwecks spaeterer Identifizierung
ein Name gegeben werden, mit dem PRIORITY-Attribut wird die
Ausfuehrungsprioritaet der Task in Relation zu den Prioritaeten der
andern Tasks gestellt, was die Prozessorverwaltung beeinflusst, sofern
weniger Prozessoren zur Verfuegung stehen, als lauffaehige Tasks
vorhanden sind. Schliesslich kann ueber das EVENT-Attribut ein
Ereignis mit der Beendigung der zugehoerigen Task p verknuepft werden.
Dieses Ereignis - welches also eintritti wenn p beendet ist - kann in
der Task, welche p kreiert hat, abgewartet werden. Die allgemeine Form
dieser Synchronisationsanweisung lautet "WAIT(el,e2, ... em) k". Hierin
