GI - 3. Fachtagung uber Programmiersprachen: Gesellschaft fur Informatik e.V., Kiel, 5.-7. Marz 1974 (Lecture Notes in Computer Science) (German and English Edition)

Lecture Notes in Computer Science Edited by G. Goos, Karlsruhe and J. Hartmanis, Ithaca

7 GI Gesellschaft fi3r Informatik e.V.

3. Fachtagung L~ber Programmiersprachen Kiel, 5.-7. M#.rz 1974

Herausgegebenyon Bodo Schlender und Wolfgang Frielinghaus III

Springer-Verlag Berlin. Heidelberg. New York 1974

Editorial Board D. Gries • P, Brinch Hansen • C. Moler G. Seegm~ller • N. Wirth

Professor Dr. Bodo Schlender Institut f~ir Informatik und Praktische Mathematik Universit~t Kiel Wolfgang Frielinghaus Telefunken GmbH Konstanz

AMS Subject Classifications (1970): 00 A10, 02 G 05, 68-02, 68 A05, 68 A10, 6 8 A 2 0 , 6 8 A 3 0 ISBN 3-540-06666-7 Springer-Verlag Berlin • Heidelberg • New York ISBN 0-387-06666-7 Springer-Verlag New York • Heidelberg - Berlin This work is subject to copyright. All rights are reserved, whether the whole or part of the material is concerned, specifically those of translation, reprinting, re-use of illustrations, broadcasting, reproduction by photocopying machine or similar means, and storage in data banks. 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 1974. Library of Congress Catalog Card Number 74-234. Printed in Germany. Offsetprinting and bookbinding: Julius Beltz, Hemsbach/Bergstr.

~orwqrt Unter den Fachtagungen der Gesellschaft f ~

Infermatik

ist dies die dritte, die speziell den Programmiersprachen gewidmet ist. Die Vorg~ngertagungen fanden im M~rz 1971 in MGnchen*) und im M~rz 1972 in SaarbrGcken**) W~hrend die Jahrestagar~en der GI versuchen,

statt.

einen Uberblick

Gber alle wesentlichen Bereiche der Informatik und einen wissenschaftlichen Gedankenaustauseh Fachgebieten zu vermitteln,

zwischen verschiedenen

ist es der Zweck der Fachtagungen,

den wissenschaftlichen Fortschritt

in einem Spezialgebiet

in Vortrag ~md Diskussion der Offentlichkeit Zur Entwicklung des Fachgebietes in r e g e l m ~ i g e n

darzustellen.

ist es einmal netwendig,

Zeitabst~nden Gelegenheit zu geben, ~ber

die letzten wissenschaftlichen Forschungsergebnisse berichten,

zu

zum anderen mGssen Arbeiten aus den Anwendungen

vorgestellt werden k~nnen, um die erforderliche gegenseitige Anregung von Theorie und Praxis Wirklichkeit werden zu lassen. Um eine vernttuftige Gliederung der Tagung zu erm~glichen, ist es zweckm~Big,

dan der Programmausschu~

in der Einladung

zur Anmeldung von Vortr~gen spezielle Schwerpunkte setzt. FGr die gegenw~rtige Fachtagung waren dies die Gebiete Semantik von Progra~miersprachen, Ubersetzerbau, Dialogsprachen und Programmiersprachen fGr Proze~rechner. Der Programmausschu~ war bei der Zusammenstellung programmes b e m ~ t ,

des Tagungs-

diejenigen Vortr~ge auszuw~hlen,

die den

oben genannten Zielen einer Fachtagung am besten entsprachen. Uberdies war es m~glich, eine Reihe von international bekannten Wissenschaftlern zu einftLhrenden Hauptvortr~gen zu gewinnen.

*)

Lecture Notes in Economics and Mathematical Systems, Band 75, Springer-Verlag, Berlin . Heidelberg . New York 1972 **) Gesellschaft fiLr Informatik e.V., Bericht Nr. 4, ver~ffentlicht durch die Gesellschaft fGr Mathematik und Datenverarbeitung mbH, 5205 St. Augustin 1, 1972

IV Dem Programmausschu~

geh~rten an:

VI Erfahrungen mit einem Parser-Generator Chomsky-Grammatiken R. Nollmann

fGr

......................................

114

HAU~TVORTRAG : Structured Programs, Arcadian ~achines and the Burroughs W.T. Wilner

......................................

Struktureinheiten ihre 0bersetzung W. Niegel

B1700

in kontextfreien

133

Sprachen und

........................................

149

ALSI - eine h~here Progrsanniersprache zur Transformation v o n ALGOL 68 - Verbunden in SIMULA-Klassen

U. Kastens

.......................................

162

Interaktives Trace- und Debugging-System ALGOL KIEL X 8 J. Baginski,

H. Seiffert

.........................

173

HAUPTVORTRAG: Some Characteristics to Process Control J.G.P.

Barnes

of RTL/2 and their Relevance

....................................

ProzeBorientierte Funktionen

Programmiersprachen,

G. Koch, V. Kussl

189

Formen und

................................

199

Ein Vergleich von Prozess-Kontroll-Sprachen als Basis fGr den Norm~magsvorschlag einer internationalen ProzeBrechnersprache K.F. Ereuter

.....................................

219

ZUM BEGRIFF DER MODULARIT~T VON PROGPJ~MIERSPRACHEN

H. LANGMAACK

I. Modulares Proqrammieren

Die gegenw~rtige Arbeit schlieBt an Uberlegungen an, die J.B. Dennis in seiner Schrift "Modularity"

[3] angestellt hat. Er hebt dort die folgen-

den Ziele modularen Programmierens hervor: I. Man muS sich yon der Korrektheit eines Programmmoduls

unabhMnqig vom

Kontext in gr~8eren Softwareeinheiten ~berzeugen k~nnen. 2. Man muS Programmmodule ohne Kenntnis ihrer internen Arbeitsweisen zusammensetzen k~nnen. Diese Ziele verk~rpern auch den Begriff der Kontextunabh~n~i~kei~ bei W.E. Boebert

[2] °

In ALGOL-artigen Programmiersprachen

sind es offensichtlich die Proze-

duren, die fHr die Betrachtung als Programmmodule

in Frage kommen. Da-

bei muB man sich abet auf diejenigen Prozeduren beschrMnken,

die keine

nicht lokalen

in einem

(globalen)

Parameter haben,

da ihre Verwendung

Progranmmloduldas Konzept der Modularit~t verletzen w~rde. Lediglich das Auftreten globaler Standardidentifikatoren

darf erlaubt sein, die wir

der Einfachhelt halber zu den Grundgr~Ben der Programmiersprache

hin-

zuz~h!en.

Wir nennen ein Programm modular, wenn in ihm~ nur Prozeduren ohne globale Parameter Verwendung

finden. Nach Dennis ist Modularit~t aber nicht

bloS eine Eigenschaft einzelner Programme,

vielmehr sollte HodularitMt

vor allem als Eigenschaft einer Programmiersprache den. F~r Programmiersprachen

se!bst angesehen wet-

erhebt sich n~mlich die Frage, ob jedes

Programm in ein ~quivalentes modulares Programm der gleichen Sprache

9erwandelt werden kann. Wenn das zutrlfft~ eann wollen wir eine P r o g r ~ miersprache modular nennen.

Bislang ist der Begriff der Modularit~t von Programmiersprachen nicht vo!!st~ndig umrissen. des Begriffs ~quivalenz

noch

Noch h~ngt er yon einer prMzisen Fassung

ab. Die funktiona!e ~quivalenz,

bei der zwei

Programme ~quivalent heiBen, wenn sie das gleiche Ein-Ausgabeverhalten zeigen, ist wenig sinnvo!l.

Denn sonst g~be es zu jedem Programm einer

ALGOL-artigen Programmiersprache ein ~quivalentes prozedurloses, modulates Programm,

also

und jede ALGOL-artige Programmiersprache w~re tri-

vialerweise modular.

Bei der Umwandlung eines Programms in ein ~quivalentes modulares sol!te die Prozedurstruktur

im wesentlichen erhalten bleiben.

Modularit~t

sollte vornehmlich dadurch erzielt werden k~nnen, dab globale Parameter in lokale verwandelt werden. Versierte Programmierer kennen diesen Prozess sehr gut, und oft h6rt man die Meinung, die Verwandlung Parameter sei doch stets m~glich.

in lokale

Auf dabei sich zeigende Probleme weist

bereits Dennis in [3] hin, und wir werden sehen, dab dieser Verwandlung Grenzen gesetzt sind

(Satz 3 und 4).

2. Formale ~quivalenz yon Pro@rammen Um dem Erfordernis nach Erhaltung der Prozedurstruktur entgegenzukomment f~hren wir den Begriff der formalen ~quivalenz ein. Dabei stOtzen wir uns auf die Programmiersprache ALGOL 60, die wir zum Zwecke pr~ziser Formulierungen zu ALGOL 60-P nut unwesentlich modifizieren. gegenOber ALGOL 60 in folgender Weise abgewandelt a) Es sind nur eigentliche Prozeduren,

ALGOL 60-P ist

[5] :

keine Funktionsprozeduren

zuge-

lassen. b) Wertaufruflisten und Spezifikationen c) Es sind nur Identifikatoren

in Prozedurdeklarationen

fehlen.

als aktuelle Parameter in Prozeduran-

weisungen erlaubt. d) Neben begin und end haben wir ein zus~tzliches Paar yon Anweisungsklammern {

}. Sie wirken wie Block-begin und Block-end.

Wir verlangen,

dab alle Prozedurr~mpfe in diese Kiammern eingeschlossen sind, und wir nennen sie in diesem Kontext ~umpfklammern. sie Aufrufklammern.

In anderem Kontext heiSen

Wir benStigen diese Klammern, um originale Program-

me, die der Programmierer geschrieben hat, von Progr~mmen zu unterscheiden, die durch Anwenden der Kopierrege! entstanden sind.

ES d~rfte klar sein, was ein syntaktisches heist dazdiber hinaus kators

formal,

genau ein definierendes

durch zul~ssige

Umbenennung

sehen wir als identisch gezeichnet

angenommen

von Identiflkatoren formales

Programm

[7] ), wenn vern~nftig

an. O.B.d.A. werden,

eines

Formale forma!e

Programme, Programm

Identifikatoren

benannt.

und Hbersetzt

kompilierbar,

leere R~mpfe

werden k~nnen.

{ } das resultierende

Programm,

und K' sei formal.

Sei f(al,~..,a n) eine Prozeduranweisung

die zugeh~rige

Prozedurdeklaration

yon n garantiert

die gleiche

Wir d~rfen

dadurch,

Dabei ~m

~ = ... proc '= ~---,I ÷ formales

der KoDierregel

~

. Die partie!!e

n der aktuellen

(~ ~---~')~ im Haupt-

~ als ausgezeichnet Block,

voraussetzen.

ersetzt wird,

Rumpf

Parameter

} urn 9

~' aus

{ ~ m } yon Parameter

a i ausgetauscht

in ~ zu Aufrufklammern

in ~' geworden.

f(x 1...... X n ) ; ~ { ~ } _ i ; ~ < . i ~ ( a l

proe f(xl,. und~ w

'Xn) ; { ~ } ; ' ' ~

sind Relationen

Programm

E~ yon

nigen Programmen

..... an);...

{

~m

in der Menge

~ heist original,

nur als Rumpfklammern heist die Menge die Ausf~hrung

{

Para-

Dann entsteht

wobei die formalen

aktuellen

sind die Rumpfklammern

Kompilierbarkeit

und formalen

daS f(al, .... a n ) durch einen modifizierten

{ ~ }, einen erzeu~ten

} um

Dann heiBt

; {9 };

Anzahl

x i in { ~ }durch die entsprechenden {

Pro-

von ~ . Sei = proc f(x I ..... x n)

werden°

Ein

wenn nach Ersetzen

sich aus ~ durch Anwenden

meter.

Vor-

sind diejeni-

es von ~', es ergebe programm

Ein 68-

gem, S seines definierenden

wenn

gilt:

als aus-

Vorkommen

wie im ALGOL

Programme

die

hervorgehen,

ist.

kompilierbares

fo!gendes

~ ist. Identifi-

definierende

(oder eigentlich

akzeptiert

{9} durch

~e kompilierbar

sei partiell

darf jedes

ist. Kompi!ierbare

n heist partiell

aller Prozedurr~mpfe

60-P-Programm

auseinander

d.h. verschiedene

jeder Identifikator angewandt

gen, die von einem Kompiler Programm

geh~rt.

sind dutch verschiedene

Bericht

gramm

Vorkommen

von Identlfikatoren

heist kompilierbar

kommens formales

ALGOL

wenn zu jedem Vorkommen

verwendet

""

der formalen

Programme.

wenn die Anweisungsklammern

sind.

FUr ein originales

Ein

{ }in

Programm

:= { ~ ' i ~ - - ~ , } ~. Der A__usfHhrungsbaum T~ yon ~ besteht

in E~xdie h~chstens

ein innerstes

aus denje-

Aufrufklamrnernpaar

besitzen.

Jedes Programm

(jeder Knoten)

K" in TH besitzt h6chstens einen

unmittelbaren Vorg~nger ~'~----H" in E~.

Um zum Begriff der formalen ~quivalenz von Programmen zu gelangen, f~hren wir den Begriff der reduzierten AusfOhrung ein. Wir bilden fHr jedes Programm H' e EH das zugeh6rige Hauptp~ogramm H' durch Streichen m aller Prozedurdeklarationen, wir ersetzen jede verbliebene Prozeduranweisung in H' durch ein Spezialsymbol, z.B. call, und wir nennen das m ........... Ergebnis das reduzierte Hauptpr0gramm Hr y o n Nw

ErH := {~IH'

~

E H}

heiBt die reduzierte Ausf~hrun~, TrK

:= {H$IN'

~ TH}

der reduzierte Ausf~hrungsbaum yon H. Zwei origlnale Programme heiBen nun formal ~quivalent, wenn ihre reduzierten AusfHhrungen bzw. Ausf~hrungsb~ume identisch sind. Damit ist die formale ~quivalenz

zweier

Programm~so eingef~hrt worden, dab sie im wesentlichen gleiche Prozedurstrukturen haben. Ferner gilt der

Satz I: Formal ~quivalente Programme sind auch funktional ~quivalent.

for~.j

Von einem originalen Programm H heigt es, es habe|korrekte Parameter~bergaben,

wenn alle Programme H' E E H bzw. T H Dartiell kompilierbar

sind. H heiBt dar~ber hinaus MakroDroqramm, wenn E H bzw. T H endlich ist. Makroprogramme

sind diejenigen,

grammtechnik

implementiert werden k~nnen.

die mit Makro- oder offeney

der f~r gegebenes originales Programm H entscheidet, Parameter0bergaben

Unterpro-

Es gibt keinen Algorlthmus, ob H formal korrekte

hat bzw. ob H Makroprogramm ist. Wir haben jedoch den

Satz 2: Formale Kquivalenz von Programmen ist invariant gegen~ber den beiden Eigenschaften,

formal korrekte Parameter~bergaben

zu haben bzw.

Makroprogramm zu sein. 3. Die Nichtmodularit~t

yon ALGOL 60-P

Wir wollen nun der Frage nach der Modularit~t von ALGOL 60-P nachgehen. Diese Frage h~ngt sehr eng mit dem Entscheidungsproblem rekte Parameter~bergaben zusammen. bale formale Parameter, lich entscheidbar,

fur formal kor-

F~r ALGOL 60-P-Programme N ohne glo-

d.h. fur die Teilsprache ALGOL 60-P-O, ist n~m-

ob H formal korrekte ParameterHbergaben hat. Wenn

wir nun ein effektives Verfahren h~tten, das jedes originale Programm H in ein formal ~quivalentes modulares verwandelte, dann h~tten wir

auch eine positive LIsung des genannten Entscheidungsproblems

fir

ALGOL 60-P. Daher gilt der manchen Progra~mierer iberraschende Satz 3: Es gibt kein effektives Verfahren, das jedes originale ALGOL60-P-Programm in ein formal iquivalentes modulares der gleichen Sprache verwandelt. Dieser Satz liBt zwar die Nichtmodularitit von ALGOL 60-P vermuten, beweist sie jedoch noch nicht. Dazu missen wir erst ein Programmbeispiel konstruieren, das zu keinem modularen Programm formal Iquivalent ist: ~i = be~in proc M(x,y);{ x(y)}1 proc E(n) ;

{

};

proc L(x,y) ; {pr0c A(n) ; {n(x,M)}; proc ~(~,~) ;{~(~,y)}; L(A,A) ;M(A,A) } ; L (E,M) end

T ,~,);MCA',~')}... ...{...T(~, ...{A' (A') }... T

...{ }... ...{...L( AT('~),~('~I;M(A(v),~.('J))}...

J

5 Knoten, siehe unten ~ > 2

. . . { a (~) (X('~)) } , . .

{~(~(a (u-l) ,M) } . . . ... {M(~,,-1).~

,~ (,>-1))}... ~

T

{M(A',A') }... T {A' (~') }... T

{i' (E,M))...

Knoten

{M(ETM) }... T {E (M~}. °.

{

}...

j

Die Identifikatoren A (v) , A(~)

bezeichnen m o d i f i z i e r t e

zeduren A, A. Der A u s f H h r u n g s b a u m der nat~rlichen

T~I

Zahl ~ existiert ein Knoten,

derart dab der aufsitzende

Kopien der Pro-

ist offenbar unendlich,

T e i l b a u m endlich

und zu je-

z.B . . . . {M(A(~),A(~))}..., ist und eine Tiefe >~ besitzt.

Dann aber kann K1 zu keinem m o d u l a r e n Prograr~m formal ~quivalent

sein.

Satz 4: ALGOL 60-P ist nicht modular.

Dagegen gilt Satz 5: ALGOL

60-P-O ist modular;

jedes orlginale Programm

es gibt ein effektives Verfahren,

in ein formal ~quivalentes

modu!ares

das

verwan-

delt. Das V e r f a h r e n werde Parameter

am Beispiel

~2 demonstriert r u m

dort die g l o b a l e n

a und p der Prozedur q zu eliminieren:

E2 = be~in proc p(x) ; {real a; proc q(y) ; {a:= 2+a;p(q) ;y(p) ;q(y) }; x(q) ;p(x) }; p (p) Im transformierten

end

Programm

formale Begleitparameter

~

haben die Prozeduren

~,~,x,~,q,~,y,~

p und q zus~tzliche

erhalten:

{real a; proc q(U~,~,y,~,~) ; {[/ := 2+~; ~( x(~,~,q,a,p) ; p( p( In P r o z e d u r a n w e i s u n g e n

, ~p,

, ~q,q,~) ; , ,x,~,x) };

, ) end

erhalten forma!e Identifikatoren

aktuellen B e g l e i t p a r a m e t e r

x,~,y,~,

meter a,p. Die aktuellen B e g l e i t p a r a m e t e r tifikatoren

anderer nicht formaler

sind unwichtig und k~nnen irgendwelche

toren sein. A n s c h l i e B e n d w e r d e n

x und y die

q erh~it die aktuellen Begleitpara-

im Rumpf von q

Iden-

lokale Identifika-

a,p durch ~,~

ersetzt.

Wer auf dem Standpunkt stehtlselbst q sei globaler Parameter yon q kann auch diesen Parameter in einen lokalen formalen verwandeln. F~r das

Programmbeispiel K3 = be@in proc q(r); {proc f(x) ;{r(x) }; q(f) ;f(r) }; q (q) end mit dem Aufrufbaum T~3

~3

T

• ..{...

;q(f') ; f' (q) .

}

~

...{...

;q(f") ;f" (f') } . . . . . .

"

T

{q(q) }...

. ...{f' (f') }...

• ..{{(f') }... und d e m globalen

formalen Parameter

unendlich viele Begleitparameter f',f",..,

ben~tigt.

bezeichnen modifizierte

4. Eine modulare Obersprache

transformieren

Kopien der Prozedur

anderen den Vorteil,

kann,

nimmt und der Reihe nach unmittelbar diese Welse wird vermieden,

empfindlich

Xl,...,x n

neue Prozedurdeklara-

schafft, st~ren.

Programmiersprache

die die Einsicht

in

Daher r~hrt der Wunsch, ALGOL 60-P-G zu er-

in ALGOL 60-P-G haben die Form

(~) prQc f (x I .... Xnf);{ Die Identifikatoren

dab man sie

hinter das erste begin setzt. Auf

dab die Kopierregel

ALGOL 60-P zu einer modularen weitern. Prozedurdeklarationen

f.

indem man ihre Prozeduren heraus-

tionen mit neuen Prozeduridentifikatoren das Wirken der Kopierregel

Die Identifikatoren

yon ALGOL 60-P

Modulare Programme haben gegenHber formal ~quivalent

r von f hMtte ein analoges Verfahren

yl,...,ymf

~

};.

heiBen formale Parameter

sind die formalen Parameter

neuer Art,

alter Art.Wenn mf oder nf Null

sind, sch~eiben wir die spitzen bzw. runden Klammern nicht. Alle ~brigen Deklarationen

sehen wie in ALGOL 60-P aus.

Ein Term ist eine endliche

Zeichenreihe,

die nach folgenden Regeln ge-

bildet wird: I. Identifikatoren

sind Terme.

2. Wenn ~ Identifikator auch ~ ein

ist und ~!r.~.,~m, (echter)

Term.

m ~ i, Terme sind, dann ist

~i ist aktueller Parameter neuer

Art. Ein sYntaktisches taktischen ALGOL

ALGOL 6 0 - P - G - P r o g r a m m ~ 60-P-Programm

neue K6pfe der obigen Form wandt vorkommende

entsteht

~' dadurch,

in ~' durch

(~) ersetzt w e r d e n und dab man in K' ange-

Identifikatoren

durch Terme auswechselt.

~brigen Begriffe

!assen sich ohne Schwierigkeit

dehnen.

fur das Wirken der Kopierregel:

Beispiel

nun aus einem syn-

da~ Prozedurk~pfe

Auch a!le

auf ALGOL 60-P-G aus-

~4 = begin proc f<{>(r) ; {f(x) }; proc q(r) ;{q(f) ; f(r) }; q (q) en d

T

; f(q)~z~...

• ..{q(f)

•..

I {q (f>) ; f> (f)} ...

T

• ..{q(q) }...

T

T •..

{f (f) }.. • • ..{q(f)

}...

T Satz

I und 2 gelten auch fur ALGOL

ALGOL

60-P-G sind nur u n w e s e n t l i c h

60-P-G.

Die Sprachen ALGOL

verschieden,

60-P und

wenn man sich auf Pro-

gramme ohne formale P r o z e d u r a n w e i s u n g e n

beschrMnkt.

liegt in der Methode wie man P r o z e d u r e n

f, die durch formale Prozedur-

anweisungen

(i) aufgerufen w~rden,

mit aktuellen Parametern

In ALGOL 60-P w e r d e n alle aktuellen P a r a m e t e r ~bergeben. ebenfalls

Der U n t e r s c h i e d

In ALGOL 60-P-G w e r d e n die aktuel!en P a r a m e t e r im Moment des Aufrufs ~bergeben,

meter neuer Art

~5 = begin real a; proc q(y);{y(q)};

Aufrufs (i)

proc f(x) ;{r := 2+r; x(f) }; q (f)

T

end

als ob sie bereits

als der P r o z e d u r i d e n t i f i k a t o r

aktueller Parameter eines v o r a n g e g a n g e n e n

(3)

alter Art

w ~ h r e n d die aktue!len Para-

(2) so betrachtet w e r d e n k~nnen,

vorher ~ b e r g e b e n w o r d e n w~ren,

versorgt.

im Moment des Aufrufs

f als

(3) auftrat.

Beispiel:

[ (2) • . . { f < a > ( q )

}..

T

...{a := 2+a; q(f)}...

T Aus der Wirksamkeit der Parameter neuer Art r~hrt der

Satz 6: ALGOL 60-P-G ist modular;

es gibt ein effektives Verfahren,

das

jedes origina!e Programm in ein formal ~quivalentes modulares umwande!t.

Die Anwendung dieses Verfahrens

~

auf Programm 93 liefert

= beqin proc q(r) ; {proc f<~> (x) ; {f-(x) } ; q(f) ; f(r) }; q (q) end

Hier bekommt nur die Prozedur f einen formalen Begleitparameter Art. Der aktuelle Begleitparameter neuer Art yon f i s t wird im Rumpf von f

r durch f e r s e t z t . ~

f neuer

r. AnschlieSend

und ~w sind offensichtlich

formal ~quivalent.

Satz 7: Die in Satz 5 und 6 genannten Verfahren lassendie Eigenschaften einer Prozedur,

formal erreichbar bzw.

Dabei heiBt eine Prozedur ~ 9' in TE existiert, Rumpf einer rekursiv,

formal rekursiv zu sein, invariant.

in 9 formal erreichbar,

falls ein Programm

dessen innerster erzeugter Block modifizierter

(eventuell modifizierten)

falls Programme ~ ' ~ - - ~ "

Kopie von ~ ist. ~

in T~ existieren,

zeugte Bl6cke modif±zierte R~mpfe von Kopien von ~

heiBt formal

deren innerste er-

sind.

Erst die Einbettung yon ALGOL 60-P in die modulare Sprache ALGOL 60-P-G hat einen durchsichtigen Beweis fur die algorithmische Unl~sbarkeit des Makroprogrammproblems n~gt es n ~ l i c h ,

fHr ALGOL 60-P geliefert

[6] . Wegen Satz 2 ge-

in ALGOL 60-P-G Programme ohne Prozedurschachtelungen

zu betrachten. FHr die Teilsprache ALGOL 60-P-F yon ALGOL 60-P-G derjenigen Programme ohne Parameter alter Art gilt aufgrund des in Satz 6 genannten Verfah-

J0

rens

Satz 8: ALGOL 60-P-F ist modular,

den Makrogrammatiken von M.J.

Die ALGOL 60-P-F-Programme ohne Prozedurschachtelungen scher

k~nnen mitlFi-

[4] identifiziert werden. Deshalb sind das Problem der formal

korrekten ParameterSbergaben und das Makroproqrammproblem 60-P-F algorlthmisch

fSr ALGOL

l~sbar. Wei! die belden Sprachen ALGOL 60-P und

ALGOL 60-P-F Jeweils Randmengen yon ALGOL 60-P-G darstellen, wird ihr gegens~tzliches Verhalten verstMndlich.

5. Zur Imp!ementierun~ von ALGOL 60-P-G Nachteilig

fSr die Implementierung von ALGOL 60-P-G ist zun~chst, dab

bel sukzessivem Anwenden der Kopierregel die aktuellen Parameter unvorhersehbar umfangreich werden kOnnen

(siehe ~ ) ,

so daS sie nicht mehr

wie bei ALGOL 60-P in jeweils elner Zelle Platz finden.

Selbst wenn

ganze AusdrScke wie in ALGOL 60 oder Anwelsungen wie in ALGOL 68 als aktuelle Parameter zugelassen sind, kann man sich auf ALGOL 60-P zurSckzlehen,

indem man "dicke" aktuelle Parameter zu RSmpfen parameter-

loser Prozeduren macht und die Parameter selbst durch die zugeh~rigen Prozeduridentifikatoren nicht weiter.

ersetzt.

Dieser Weg fShrt bei ALGOL 60-P-G

Bei geeigneter Verweistechnik

im Laufzeitkel!er

[I] kann

man aber auch hier alle aktuellen Parameter in jeweils einer Zelle unterbringen. GewShnliche und formale Prozeduranweisungen f (al,.--,a n) bzw.

x(a I,.., san )

seien auf folgende Weise in Maschinencode 8bersetzt: UNT

Gew Proz Anw

bzw.

UNT

x

f


(aI ,

a);

b i'

n

R:

m

an) ;

R~

Form Proz Anw

11

Das Laufzeitunterprogramm 60-P.

In den Speicher

Gew Proz Anw arbeitet ~hnlich wie bei ALGOL

for die neue Inkarnatlon

If von f wird der Reihe

nach eingetragen: !. Der Identifikator statisches Niveau,

f als Repr~sentant

f~r n6tige Merkmale von f wie

statischer Vorg~nger,

Startadresse,

Parameterzahlen

mf und nf, Festspeicherl~nge; 2. die R~ckkehradresse

R;

3. das dynamische

Niveau

~V des dynamischen

4. das dynamische

Niveau

~S des statischen Vorg~ngers

Iv geh~rlgen

statischen Verweiskette

Vorg~ngers

Iv yon If; yon f in der zu

KIv;

5. f~r jeden aktuellen Parameter b i wird eingetragen: a. b i gekoppelt mit dem dynamlschen Prozedur

b. der Inhalt ~er zu b i geh6rigen formaler

Niveau

in K I , falls b i gew~hnllcher Identlflkator

c. die Anfangsadresse

~i der zu b i geh~rigen

Identifikator

Speicherzelle

ist;

in KIv, falls b i

ist; B i von b i gekoppelt mit ~ f a l l s

b i echter Term

ist; 6. mit a i wird wie in 5. verfahren. Das Unterprogramm

Form Proz Anw arbeitet

O. Der Inhalt C ~ ~S der zu x geh~rigen holt. a. C ist Prozeduridentifikator

so:

Speicherzelle

in KIv wird ge-

f. Es folgen die Schritte

1.-4.,6. wie

oben. b. C ist Anfangsadresse

eines echten Terms

C: f
bm> im Hauptteil nach:

der zu ~

geh~rigen Prozedur.

S

Eingetragen

w i ~ der Reihe

1.-3. Wie oben; 4. das dynamische ~S geh~rigen 5. wie oben mit

Niveau

~

des statischen Vorg~ngers

statischen Verweiskette

von f in der zu

K6S;

K6S statt KIv und $S statt ~V;

6. genau wle oben. Die implementierung

der vera!igemeinerten

Sprache

ist also kaum schwie-

riger als die yon ALGOL 60. Hinzu ko~mt, daS Satz 6 einen klaren effektiven Weg bietet,

Prozedurgebirge

vieler Index- oder Displayregister

abzutraqen,

um das Fehlen gen~gend

auszugleichen.

12

Literatur

[I]

Bauer,

F.L., Goos, G.:

Berlin - Heidelberg [2]

Boebert,

W.E.:

Programming: nett. [3]

[4]

Syst.

Ed.: F.L.

Springer

1973.

Fischer,

M.J.:

Ling.

Bauer.

and Autom.

H.: On Correct Procedure

Math.

Wijngaarden,

Languages.

u. Informatik,

Productions.

Report No.

Harvard Univ.,

Parameter T r a n s m i s s i o n

Acta Informatica

2, 110-142

as Open Subroutines. Univ.

d. Saarlandes,

in (1973).

Fachbereich Bericht A 73/04

in Acta Informatica.

A. van, Mailloux,

Report on the Algorithmic

Anschrift

and

- New York:

May 1968.

H.: On Procedures

(1973); erscheint

1968.

in Economics

Translation,

Langmaack,

79 - 218

and Systems Press

Lecture Notes

Mass.

Langmaack,

In: Modular

Ed.: T.O. Bar-

In: A d v a n c e d Course on Software

Cambridge,

Angew.

[7]

Information

System.

Symposium.

Grammars with Macro-like

Higher Programming [6]

1971.

81, 128 - 182, Berlin - Heidelberg

NSF - 22, Math.

[5]

Mass.:

of a National

J.B.: Modularity.

Engineering. Math.

Zweiter Tell.

Springer

Toward a Modular Programminq

Proceedings

Cambridge,

Dennis,

In~ormatik,

- New York:

B.J., Peck, J.E.L.,

Koster,

Language ALGOL 68. Num. Math.

C.H.A.:

14,

(1969).

des Verfassers:

Prof. Dr. Hans Langmaack,

wandte M a t h e m a t i k

und Informatik

der Universit~t

D-66 Saarbrflcken,

Bundesrepub!ik

Deutschland.

Fachbereich

des Saarlandes,

Ange-

ENTSCHEIDBARKEITSPROBLEME

BEI DER OBERSETZUNG VON

PROGR2hMMEN MIT EINPARAMETRIGEN PROZEDUREN

W_~. Lippe

I. Einleitung und Problemstellun ~ Um effiziente Zielprogramme bei der Obersetzung yon Programmen ALGOL~hnlicher Programmiersprachen mit Prozeduren zu erzeugen, folgende Fragen berelts zur ~bersetzungszeit

sollte man

algorithmisch beantworten

k~nnen: i) Hat ein Programm formal korrekte Parameter~bergaben? 2) Ist eine Prozedur formal erreichbar? 3) Ist eine Prozedur formal rekursiv? 4) Ist eine Prozedur stark rekursiv? 5) Hat ein Proqramm die Makro-Programm-Eiqenschaft? F~r ALGOL 60-P sind die Eigenschaften

i)-5) unentscheidbar,

5) f~r ALGOL 60-68, obwohl nur Identifikatoren

ebenso 2)-

als aktuelle Parameter

zugelassen sind [4,5]. Zum Beweis der Unentscheidbarkeit

der formalen Erreichbarkeit von Pro-

zeduren wird in [4] f~r jedes Postsche Korrespondenzsystem L

ein Pro-

gramm ~r mit einer Prozedur ~ 4 effektiv konstruiert,

so dab

dann eine L6sung hat, wenn ~

ist. Es f~llt auf,

in ~r formal erreichbar

dab in n~ nur solche Prozeduranwelsungen nen

ao(al,...,an)

~

genau

auftreten, bei de-

alle formalen Identifikatoren a i paarweise verschieden sind.

Wit nennen nun ein Programm monadisch, wenn f~r die formalen Identifikatoren ai,a j in jeder Prozeduranweisung

ao(al,...,an)

a i = aj ist~

Damit stoSen wir auf die Vermutun@

i: F~r monadische ALGOL 60-P Programn~ist entscheidbar,

ob

eine Prozedur formal errelehbar ist. Diese Vermutung ist dem bekannten Satz von L~wenheim und Skolem

[~]ana-

14

log, welcher besagt, da~ der Pr~dikatenkalk0l

erster Stufe mit nur mo-

nadischen Pr~dikaten entscheidbar ist. Die von Church bewiesene Unentscheidbarkeit des vollen Pr~dikatenkalk01s Unentscheidbarkeit

ALGOL 60-P-Programmen.

Die formalen Identifikatoren entsprechen ge-

wissermaSen den Individuenvariablen, Identifikatoren

erster Stufe entspricht der

der Erreichbarkeit von Prozeduren in generellen

die zusammengefaSten gew~hnlichen

in einer Prozeduranweisung

entsprechen einer Pr~dika-

tenvariablen. Durch ganz ~hnliche Argumentation kommt man zu der

Vermutung

2: FUr ALGOL 60-68-Programme mit endlichen Arten ist entscheidbar,

ob eine Prozedur formal erreichbar ist.

Bislang ist es nicht gelungen, beweisen.

die beiden Vermutungen vollst~ndig zu

FUr Programme, die der Einschr~nkung A unterliegen,

sind die

Vermutungen jedoch richtig, wie wir zeigen werden. Einschr~nkung A: Nur einparametrige Prozeduren und Prozedurschachtelungstiefen ~2 sind zugelassen.

15 2. U berfuhrung in die sprache ALGOL 60-P-G Um die Beweise zu vereinfachen, machen wir ferner die unerhebliche Einschr~nkung, dab es neben Prozedurdeklarationen tionen und neben einparametrigen

keine weiteren Deklara-

Prozeduranweisungen

keine weiteren An-

weisungen geben soll. Programme mit diesen Einschr~nkungen besitzen die allgemeine Form: begin

proc gl(Xl);

{ ~

fll(Yll); :

{ ...... }; Hauptteil yon fll

proc flm I (Ylm I) ; { ..... }; I

Hauptteil von gl

}; proc g2 (x2) ; {proc f21(Y21);

( ..... };

proc f2m 2(y2m2) ; { ..... }; .

}; proc gn(Xn) ; {proc fnl(Ynl);

{ ..... };

®

rp-r-g-qfnm n(ynm n) ; { ..... };

}; • gi(gi ,) ; •

~

Hauptteil des Hauptprogramms (I ~

i,

i'

~ n)

end Es ist klar, dab jedes originale Programm dieser Bauart formal korrekte Parameter~bergaben hat. Betrachten wit nun alle m~glichen Arten von Prozeduranweisungen eines solchen Programms. a) Im Hauptteil des Hauptprogramms k6nnen nur Anweisungen gi(gi ,) stehen (I ~ i,i' ~ n). b) Im Hauptteil der Prozedur gi(i lest) sind folgende Arten von Prozeduranweisungen m~glich: (I ~ i,i' S n;l ~ j,j' ~ m i)

16

c)

gi' (gi '')

fij (gi ")

xi (gi '')

gi' (fij ')

fij (fij ')

xi (fij ~)

gi' (xi)

fij (xi)

xi (xi)

Im Hauptteil der Prozedur fij (i,j fest) sind folgende Arten yon Prozeduranweisungen m~glich: (i ~ i,i', i" < n; 1 _< j,j', j" _< m i) gi' (gi ")

fij' (gi '')

xi (gi ")

Yij (gi '')

gi' (fi9 ")

fij' (fij ")

xi(fij")

Yij (fij ")

gi' (xi)

fij' ( x i )

xi(xi)

Yij (xi)

gi' (Yij)

fij' (Yij)

xi (Ylj)

Yij (Yij)

Um die st6renden Prozedurschachtelungen zu eliminieren, formen wir unser ALGOL 60-P-Programm in ein formal ~quivalentes ALGOL 60-P-G-Pro gramm ohne Prozedurschachtelung um. Es gilt n~mlich folgender Satz: Satz I:

Jedes ALGOL 60-P-Programm kann effektiv in ein formal ~quivalentes ALGOL 60-P-G-Programm ohne Prozedurschachtelung transformiert werden.

F~r die genaue Definition von ALGOL 60-P-G und den Beweis des Satzes siehe [5]. Die allgemeine Form der betrachteten Programme ergibt sich nach der Transformation in ALGOL 60-P-G zu: begin proq gl (Xl) ; { . . . . . }; Haup~teil von gl proc g2(x2) ; { . . . . . };

proc gn(Xn) ; { ..... }; proq fll<Xl>(Yll ) ; { ..... }; • Hauptteil von fll proc flml<Xl>(Ylml);{ ..... }; rp_r~ f21<x2 > (Y21) ;{ ..... };

pr0c f2m2<X2 >(y2m2 ) ; { ..... };

17

proc fnl < Xn>

(Ynl) ; { ..... } ;

proc fnm 2 <Xnb (Ynm n) ;{ ..... }; A I

Hauptteil des [I Hauptprogramms

gi °(gi') ; end

Die entsprechenden Prozeduranweisungen im ALGOL 60-P-G-Programm lauten: a) Im Hauptteil des Hauptprogramms (i ~ i,i' ~ n) : gi(gi ,) b) Im Hauptteil yon gi(i fest; 1 S i,i',i" S n; 1 ~ j,j' S mi) : gi~(gi,,)

fij<xi>(gi,,)

xi(gi,,)

gi, (fij,<xi >) fij<xi>(fijt<xi>)

xi(fij,<xi>)

gi,(xi )

x i (xi)

fij<xi > (x i)

c) Im Hauptteil von fij(i,j fest; 1 _< i,i,i" _< n; 1 < j,j',j" <_ mi) : gi'(gi '')

fij '<xi> (gi I~)

xi (gi ")

Yij (gi ")

gi' (fij"<xi >) fij'<xi>(fij"<xi>)

xi(fiJ"<xi>)

Yij (fij"<xi >)

gi' (xi)

fij '<xi> (xi)

xi (xl)

Yij (xi)

gi' (Yij)

fij '<xi> (Yij)

xi (Yij)

Yij (Yij)

Bei allen Prozeduranweisungen ~(8),die in Programmen~' des Ausf~hrungsbaums T H eines ALGOL 60-P-G-Programms ~ auftreten k~nnen, haben jetzt die Terme a und 8 offenbar die Gestalt: a = fikJk < fik_lJk_l < ... < f i l J l < g i > > °..>>; 8 = fi'k'J'k'
...>

k >~ O, ...>>

; k' >~ O.

Satz 2: F~r al!e Prozeduranweisungen e(B) gilt, dab der unmittelbare Teilterm u.T. des k~rzeren Terms Teilterm des l~ngeren Terms ist. Die Anweisungen e(8) lassen sich somit in Form eines Speicherbandes mit zwei Zustandsk6pfen veranschaulichen, wobei sich mindestens ein Zustandskopf immer am oberen Ende des Speicherbandes befindet. Die Bandinschrift ist hierbei der u.T. des l~ngeren Terms von a und 8.

18

Im linken Zustandskopf befindet sich das Anfangssymbol Zustandskopf das Anfangssymbol

von ~ ,im rechten

von 8 ;z.B. :

rechter Zustandskopf

• fik-lJk-l~''

I linker

ifi'k'J'k' •

Zustandskopf

3.Monadische Programme Wir untersuchen jetzt die monadischen Programme, d.h. solche mit der

Einschr~nkung

B: Bei allen Prozeduranweisungen

s(8) gilt, dab ~ = 8

ist, falls s und 8 formal sind. Diese Forderung bewirkt, dab im Hauptteil von fij(i,j fest) Prozeduranweisungen der Arten xi(Yij) und Yij(xi) nicht erlaubt sind. Mit dieset Einschr~nkung l~Bt sich f~r die Prozeduranweisungen in T n folgender Satz zeigen: Satz 3: FUr alle Prozeduranweisungen ~I

= 1

oder

~Bl = 1

s(8) gilt:

oder

ll~

- ~B~

~ I.

Dies bedeutet, daS fur die Stellung der beiden ZustandskSpfe Band nur folgende Konfigurationen

1....

I

-- -

I~

oder

auf dem

erlaubt sind:

1

I

t

1 ,-o

oder

t fi

I__ .....

{

I ''"

I~ I oder

~

1., •

I~ 1

A

oder

19

oder Ifi'k, J'k,l

Da folgl~h

keine

tigt wird,

liegt es nahe,

Information

fij in ~ Uber regul~re Definition: R =

aus dem Innern des Speicherbandes

die Erreichbarkelt

kanonische

Ein regul~res

Systeme

kanonisches

einer Prozedur

ben~-

gi oder

zu entscheiden.

System

ist ein 4-tupel

( ~ , % , S, ~) mit (i) ~

ist eine endliche,

nicht

leere Menge

( nicht termi-

hale Symbole). (ii) ~ ist eine endliche, nicht Syr~bole) mit ~ n ~ = ~ . (iil)

Sc%~ tionen

} fur

binare

(x,y) &

eines regul~ren

gung von Worten ergibt Definition:

Zu unserem

kanonischen

F~r x,y ~ %~,

~ , ~ e ~[

es existiert

Xl,X2,Yl£~ ~

Sei

Programm

Relation

~ schreiben

sich aus folgender

E konstruleren

auf

~

(Produk-

wir x--~ y)

Systems,

d.h.

die Erzeu-

Definition:

gilt x ~ ------>y u

x2~--~ Yl ~ Mit ~----> bezeichnen wir die transitive

nisches

(terminale

(Startworte).

(iv) ~ ist eine end!iche

Die Arbeitsweise

leere Menge

:

, so dab x = XlX2, y = xlY 1 und reflexive

H~lle von-----~ .

wir nun folgendes

regul~res

kano-

System

~:=

{gi }' 1 S

Die terminalen % := {0,g,f}

i S n, und

Symbole

mit g ~ ~

(fij},

1 ~ i ~ n, i ~ j ~ m i-

kanonischen

Systems

und f £ ~ . Die nicht terminalen

~[ := {(g,u,9,u),(g,u,9,u,L) (f,O,f,u)}

~=

des regul~ren

sind

Symbole

sind

, (g,u,f,O) , (f,O,g,u) , (f,O,f,O) ,(f,u,f,O) ,

mit g,~ 6 ~

;f,{£ ~

und u,O,L ~ ~ u %

drei verschie-

dene Symbole. FUr jede Anweisung wort @

(gi,u,gi,,u)

F~r jede Anweisung

gi(gi,)

des Hauptprogramms

wird genau ein Start-

konstruiert. im Rumpf yon gi werden genau zwei Produktionen

20

konstruiert.

Anweisung~

(gi~u,f,O)

(gi,u,g ,U)

~ (gi' 'u'gi"'U)

gi ' (gi" )

~ (gi''u'gi"'u'L)

gi' (fij '<Xi>)

~--g(gi''u'fij' ,O)

~ ~f (gi' 'u' fij 'O)

gi ' (Xi)

Z~

Z~

(gi''U'g'U)

fij <Xi > (gi")

"g (fij ,O,g~. ,U)

fij<Xi > (fij '<Xi>)

~g (fij 'O' fij ' ,0)

(gi' ,u,f,O)

4~~f (fij 'O'gi" ,u) "f (fij ,O, fij' ,O)

fij<Xi > (Xi)

g~g (fij ,O,g,u)

4~-f (fij ,O, f,u)

Xi (gi" )

Z-- (g,u,gi, ,,O)

~-- (f,O,gi.,u)

Xi (fie '<xi> )

Z~g (g,u, fij , ,0)

~--f(f,u,fij, ,0)

x i (xi)

@~ (g,u,g,u)

~-- (f,O, f,O)

FOr jede Anweisung im Rumpf von fij wird ebenfalls eine endliche Menge yon Produktionen konstrulert(s. Tafel I). Hierbei durchlaufen f,f ~,g ~und y ~u~.In der Matrix stehen die einzelnen Produktionen, wobei das nicht terminale Symbol der linken Seite sich am Kopf jeder Spalte befindet. Hinzu treten noch die Produktionen y (~,u,~,u,L) -- (~,u,~,u,L) @(~,u,~,u,L)

-~ @ ( ~ , u , ~ , u )

mit ~,g ~ ~.

~an kann nun zeigen: Satz 4: Eine Prozedur p in ~ ist genau dann formal erreichbar, falls es ein Startwort s, ein terminales Wort £ und ein nicht terminales Symbol (p,v,y,w) mit v,w 6 {u,Q}ly ~ ~ gibt mit s ~---> t(p,v,y,v). Da letzteres jedoch entschieden werden kann [l]j gilt der Satz 5: Es ist entscheidbar, ob eine Prozedur in einem ALGOL-60-PProgramm mit den Einschr~nkungen A und B formal erreichbar ist.

YiJ (Yij)

Yij (gi") Yij (fij"<xi>)

x i (xi)

xi (fij"<xi>)

xi (gi" )

fij'<xi> (Yij)

fij '<xi> (xi)

gi' (Yij) flj '<xi> (gi") fij '<xi> (fij"<xi >)

(~,O,gi..,u) (~,u,gi. ,u) (y,u, fij . ,O)

(fij' ,O,g,u)

(fij''O'y'u)

(g,utfi9.,O) (g,u,g,u,L)

(g,u,gi. ,u,L)

If 41-" (~,o,K,o) (~,u,~,u)

y~"

(fij' 'O'gi"'u) (fij' 'O' fij" 'O)

(gi' ,u,{,O) (gi' tu,g,u) (gi''u'g'u'L)

(gi''u'gi"'u'L) (gi' 'u'fij"'O)

gi' (gi'') gi' (fij"<xi>)

gi ' (xi)

(fij ,O,g,u)

Anwe i s u n g ~

(fij ,O,f,O)

(fij ,U, f,O)

-M-~ (f,O,gi. ,U) ~-~ (f,O,fij. ,0) ~-- (f,O,f,O)

f~-- (f,O,gi.,U) ~ (f,u,fij.,O) {~-- (f,O,f,O)

(Tafel I)

~ - ({,o,{,o) T~" (~,u,~,u)

~ . ({,o,gi.,u) g~'~ (~,u,gl.,U) y11"~y(Y,U, fij " ,O)

£n - ({,o,{,o)

f~-~f(f,u, fij . ,O)

{~- (~,o,~i,,,u)

(f,O,gi. ,U)

(~,u,~,u)

(~,u,gi..,U) (y,u,fij .,O) (f,O,f,O)

-- (f,O,fij.,U) ~M'~ (f,O,f,O)

g{ ~~f~" ff-~ ~~-~

"J~{- (~,o,g±.,u)

(fij''u'f'O)

(fij.,O,fij..,O) (fij . 'O'y'u)

(fij''O'gi"'u)

~1-" (gi' ,u,f,O)

~'~ (gi' ,u,f,O)

~'~ (fij' 'O'gi"'u) ~q'~ (fij' 'O'gi"'u) ] { ~ ~-- (fij' 'O'fij"'O) 41~- (fij.,O,flj.,O 1 {~ y~'~y(fij. ,O,y,u)IYf~Y f~'f(fij' ,O,f,u) ~'~ (fij''O'f'O) 1 ~I ~-- (flJ''O'f'u)

~-~ (gi''u'f'O)

~f~- (gi,,u,~,u)

-~" (gi' ,u,~,u)

"~ (gi' 'u'gi"'u'L) (gi' 'U'gi"'u'L) ~" (gi' 'u'gi"'u'L) 4~'~ (gi' 'u'fij"'O) ~'~ (gi' 'u'fij"'O) {~-" (gi' 'u'fij' ,O) ~ff~'~ (gi' ,U, ~',o) £'~" (gi' ,U,{,O) f-~-~ (gi' ,U,f,O) fl"

(fij ,O,f,u)

22

4o Programme mit endlichen Arten Im folgenden b e s c h M f t i g e n wir uns an Stelle von ALGOL 60-68 bzw.

60-P mit ALGOL-

ALGOL 60-68-G mit der

Einschr~nkung

C: Alle Identifikatoren von ALGOL

Algorithmen,

besitzen

endliche Arten

im Sinne

68.

die diese E i n s c h r ~ n k u n g

abpr~fen,

werden

in [3] und

[6]

behandelt. Die Annahmen scharf.

am Anfang von 2. zur B e w e i s v e r e i n f a c h u n g

Wir b r a u c h e n

sie aber nur so wenig zu lockern,

gramm von H genau eine weitere D e k l a r a t i o n wir nur e i n p a r a m e t r i g e proc

Bind hier zu

Prozeduren

dab im Hauptpro-

real d zugelassen

zulassen,

ist. Da

haben alle Arten die Form

(proc(... (proc(real))...)).

k--

J ~

n-mal / n Z O Mit der E i n s c h r ~ n k u n g und Yij(Yij)

C schiieBen wir alle A n w e i s u n g e n

aus, da sie nur bei unendlichen

und Ylj auftreten k6nnen. und Yij(xi) bewirken.

erlaubt,

Dagegen

beiden Zustandsk~pfe

die ein A u s e i n a n d e r l a u f e n

enth~it die A n w e i s u n g e n

sungen aus K 2 zur A n w e n d u n g

xi(Yij),

gelangen,

Die Konsequenz

sung der Art xi(Yij) z.B.

K1

Yij(xi) , fij,<xi>(Yij) ,

gilt Satz aus Satz

Solange nur Anwei-

3. Selbst durch Anwei3 nicht unbedin~t

kann nur dann verletzt werden, oder Yij(xi)

C die

ff in zwei Klassen ein:

K 2 enth~lt die ~brigen Anweisungen.

sungen aus K1 werden die K o n s e q u e n z e n letzt.

der beiden Zustandsk~pfe

auf dem Band bewegen kSnnen.

eines Programms

der Arten

von x i

der Arten xi(Yij)

dab wegen der E i n s c h r ~ n k u n g

sich nicht beliebig

Wir teilen die A n w e i s u n g e n

Yij(fij.,<xi>);

DeklaratorbMumen

slnd nun A n w e i s u n q e n

Es l~Bt sich jedoch zeigen,

der Arten xi(x i)

auf ~(~) mit

l~I =

ver-

wenn eine Anwei181 - I folgt

23

Weitere sinken Stets

Anweisungen jediglich

aus K1 verMndern

herunter,

aber resultiert

ist eine Folgerung aus K2 erfolgt, oberen Kopfes fortgefahren Diese

sie ihre Positionen 181 - 1 ~ Max

aus der Einschr~nkung

gilt wiederum

Satz

C. Sobald

3, wobei

nicht,

die K6pfe

tauschen

k~nnen.

(I~'l,18'I)

s 18 I- Dies

nun eine Anweisung

entweder

oder an der Stelle des mittleren

an der Stelle des

Kopfes

oder

"ganz unten"

wird.

anschauliche

Verhaltensweise

keit einer Prozedur Definition:

wobei

s'(8') mit

den Kellerinhalt

dutch

Stack-Systeme

Ein Stack-System (i) ~

legt es nahe,

Erreichbar-

zu entscheiden.

ist ein 4-tupel

ist eine endliche

die formale

S =

( ~ , @ ,S,~) mit

nicht

leere Menge

(nicht terminale

nicht

leere Menge

(terminale

Symbole), (ii) ~ ist eine endliche mit

~ n~ = ~

(iii) S c ~

(Startworte).

(iv) ~ ist eine endliche Formen

Menge von Produktionsregeln

(mit S,S' e~%

i) OAS

--->

; A,B {9;

2) QAS -->

OAS' 0S'

4) QASQ 2 --->

Ol AS'Q2

5) QIASQ2--~

OIS'AO 2

6) QIASBQ2-->

OlABS'Q 2

~Tie bei den regul~ren

kanonischen

Systemen

weise eines

Stack-Systems

mit

Definition:

Wir schreiben

wy~bwy':

eine Produktion ~

falls w,w' ~ ~ ,

wir wieder

Satz 9: Eine Prozedur

falls w 6 ~

Symbol

,Y,Y'6 %']q und in

Y,Y' 6 ~ % ~

Stack-System

~

s~ ein terminales

(p,v,y,w)

(p,v,ytw).

wir die Arbeits-

wir schreiben

~vw ~ w y w

und in ~ eine Produk-

reflexive

mit v,w

H~lle yon ~

konstruieren

p in K ist genau dann formal

in ~ ein Startwort

~iber

existiert.

die transitive

Wie in 2. l~Bt sich zu K ein genschaft

so dab s ~ > t

~

erkl~ren

~y--> Qy' existiert,

tion QIYQ2---~ olY'02 Mit ~-~> bezeichnen

der

Oi,Ql,O 2 Variablen

QABS'

3) QAS --->

minales

Symbole)

.

mit der Ei-

erreichbar,

falls es

Wort t und ein nicht

{u,O} und y £ ~ ~ u { d } g i b t ,

ter-

24

Da letzteres entschieden werden kann

Satz i0: Es ist entscheidbar,

[2] gilt

ob eine Prozedur in einem ALGOL 60-68-

Programm mit den Einschr~nkungen A und C formal erreichbar ist.

Literatur:

[1]

Bichi, J.R.: Regular canonical systems Arch. Math. Logik Grundlagenforschung

[2]

Ginsburg,

S., Greibach S.A.and Harrison, M.A.

Stack automata and compiling,

[3]

Koster, C.H.A.: Feb.

[4]

14(1961),

J. ACM 14,1

143-172

:

(Jan.

1967), 172-201

On infinite modes, ALGOL Bulletin AB 30.3.3,

1969, pp. 61-69

Langmaack,

H.: On correct procedure parameter transmission in

higher programming languages, Acta Informatica, Vol.

[s]

Langmaack, A 73/04,

H.: On procedures

as open subroutines,

2,1973

Bericht

Institut f~r Angew. Math. und Informatik der Univ.

des Saarlandes

[6]

Zosel, M.

: A formal grammar for the representation of modes

and it's application to ALGOL 68, Dissertation Washington,

[7]

Hilbert, D. Ackermann,

W.: Grundz~ge der theoretischen Logik

Springer Verlag 1972

Anschrift des Verfassers: Dipl.-Inform. Fachbereich

Wolfram Lippe

i0

Angewandte Mathematik und Informatik der Universit~t des Saarlandes 66 Saarbr~cken Im Stadtwald

1971, Univ. of

Bericht Nr. TR 71-10-O7

EINE

AXIOMATISCHE VON

STUDIE

ZUR

IDENTIFIKATION

IDENTIFIKATOREN KrUger

F.

1... E i n l e i t u n ~ Die i n P r o g r a m m i e r s p r a c h e n tifikator tion

mehrfach zu v e r e i n b a r e n ,

eines

(in

definierenden

der T e r m i n o l o g i e

Die v o r l i e g e n d e fikation.

Arbeit

gibt ist

es d a b e i ,

zu l a s s e n und m ~ g l i c h s t

intuitive

Betrachtung

einunddenselben

Iden-

das Problem der " I d e n t i f i k a -

durch

e i n angewandtes A u f t r e t e n " solchen

eine axiomatische

gew~hlte A x i o m a t i s i e r u n g

wir eine

schafft

Auftretens

von ALGOL 68) e i n e s

Unser Z i e ]

vortreten Um d i e

vorhandene M S g l i c h k e i t ,

Beschreibung

die n~tigen

allgemein

zu e r l ~ u t e r n

Identifikators. der I d e n t i -

Grundbegriffe

klar

her-

zu f a s s e n . und zu m o t i v i e r e n ,

m i t den z u g r u n d e g e l e g t e n

wollen

Abstraktionen

voranstellen. Der i n t u i t i v e

Sprachgebrauch

ten des I d e n t i f i k a t o r s real

x" - l e g t

x

bereits

ist

finierenden

ein

und einem B e r e i c h sein.

schlie~lich

schen B e r e i c h e n .

partielle Ordnung

Weiter

Deklarationen Grundbegriff

der P r a x i s

mit

einem de-

Zwischen e i n e r Relation

desselben eine

p

Stelle

erfUllt

Identifikators

Relation

y

zwi-

angemessen, d i e s e R e l a t i o n

und aus b e s c h r e i b u n g s t e c h n i s c h e n

soll s

die

Relation

eine Stelle

p

m i t der Ordnung

und s i n d

S P bl A bl X b2 => Der

nahe : M i t einem

GrUnden a l s

als

irre-

vorauszusetzen.

flexiv

also

als vierten

der D e k l a r a t i o n

dieses Auftretens,

verknUpft.

(Enthaltenseins-)

mehrerer

Es s c h e i n t

Grundbegriffe

Stelle

Bereieh

kann e i n e

Die M ~ g l i c h k e i t

verlangt

die

"das angewandte A u f t r e -

im G U l t i g k e i t s b e r e i c h

d i e Wahl d r e i e r

angewandten A u f t r e t e n Auftreten

- etwa d i e Phrase

liegt

Vorgang

der

Identifikation

bl

und

b2

X

vertr~glich

Bereiche,

so s o l l

sein ; gelten

S p b2 . sucht

zu einem

angewandten

Auftreten

ist :

26

eines den

Identifikators "kleinsten"

x

unter

den B e r e i c h e n von D e k l a r a t i o n e n

b e z U g l i c h d e r Ordnung

2~..... Die a x i o m a t i s c h e

sollen

Definition

Bereichsystem

B

und

Definition

ist

Mengen, y B

und

dab g i l t

p

2 : Es s e i e n

X

(B,S,y,p)

e i n Quadrupel

eine irreflexive

X

D c X xB

Uber

und

(xl,bl)

Ord-

s p b A byb'

=> s p b'

S xB

sind,

Ac

Xx S .

in

D

und

= (x2,b2)

Identifikationssys-

Ein ist

e i n Paar

(D,A)

Ein Ele ment ( x , b )

Yon

Auftreten

und

Identifikatoren

(B,S,y,p)

angewandtes Auftreten Yon 3 : (Gleichheit

, wobei

auf

ein Bereichsystem.

fur

(B,S,y,p) partielle

eine Relation

e i n e Menge von

definierendes

Definition

werden:

:

Vs E S V b , b ' E B :

tem

y.

nun f o r m a l i s i e r t

S

nung a u f derart

(Ao)

x

Beschreibung

Diese V o r s t e l l u n g e n 1 : Ein

von

x ,

ein

C D

Element

mit heist

(x,s) E A

x .

A)

<=> x l

:

x2 A b l

= b2

:

x2

:

df (xl,s~)

:

(x2,s2)

<=>

xl

A

s~

s2

df Definition

4 : Es s e i

(D,A)

(B,S,y,p) = df

Lx,b

Definition

FUr

Identifikationssystem

(x,b)

{ b' ~ B :

b'

E D

heiBt

(D,A)

geeignet

~(y,s)EA~1(x,b)CD:

sei

fur

,

x =yAsp

fur

X

wenn g i l t

:

Uber

bA(b'CLx, b =>'~spb')

da~ es zu jedem angewandten A u f t r e t e n

tifikators

identifiziertes

Die I d e n t i f i k a t i o n

Uber

dann

Dieses Axiom f o r d e r t , genau e i n

X

Y b A (x,b ') ~ D},

5 : Ein I d e n t i f i k a t i o n s s y s t e m (B,S,y,p)

(At)

•

ein

definierendes

eines

Auftreten

. Iden-

gibt.

kann d a h e r b e s c h r i e b e n werden d u r c h e i n e F u n k t i o n

27

id

: A÷D

mit id(y,s) id

Das Axiom

(At)

und d i e l a e n t i f i k a t i o n s f u n k t i o n

fe der Zuordnung

L

von T e i ! m e n g e n

von I d e n t i f i k a t o r e n , (1)

.

M

B

(At)

Definfition

Daraus

und d e r

(D,A)

(B,S,y,p) = df

Mx's Die Formel

(I)

ist

lassen

.

zu d e f i n i e r e n d e n

mit

Hil-

Auftreten

~quivalent

zu

angeben, d i e

e i n e an-

a n g e w a n d t e n

~quivalente

Formulierungen

Identifikationssystem

(x,s)EA

{b & B :

Formel

des

ableiten.

ein

FUr

B

sich

Identifikation

6 : Es s e i

formuliert

spb'

von T e i l m e n g e n von

benUtzt.

sind

Formel

noch k u r z e i n e dazu ~ q u i v a l e n t e

dere Zuordnung Auftreten

von

genauer d u r c h d i e

b ' E L x , b => ~

Wir w o l l e n

sei

spb A ( x , b ) E

fur

X

Uber

dann D } .

mit

b ' E Mx, s => m b ' y b .

(2)

D i e s e Behauptung i s t b'EMx, s , folgt

b=>mspb')]

Identifikationsfunktion.

heist

Axioms

= ( x , b ) <=> I x = y A spb A ( b ' E L x , df

so i s t

dann

gekehrt

leicht spb'

b'E Lx, b ,

(2)

d e r Annahme

und i s t spb'

folgt

einzusehen.

und mit

Gilt

(x,b')ED, (i)

also

b'E Lx, b , dann

n~mlich

(I)

und i s t

und aus d e r Annahme der W i d e r s p r u c h

so i s t

b'yb

b ' E Mx, b , m i t

und (2)

b'xb

~spb' (x,b')ED,

also

Gilt

um-

und aus

der W i d e r s p r u c h

b'yb.

3.

Zwei B e i s p i e l e

Wir w o l l e n

i n diesem A b s c h n i t t

das e i n g e f U h r t e Identifikation Als

erstes

fur

die

zwei v e r s c h i e d e n e

A x i o m e n s y s t e m angeben, in verschiedenen

Beispiel

Identifikation

w~hlen w i r

Interpretationen

die zeigen,

fur

w i e das System d i e

Sprachen b e s c h r e i b t . ein

ben~tigten

beliebiges Begriffe

ALGOL 68-Programm, range

und

to c o n t a i n

Die

28

sind

i n der S p r a c h d e f i n i t i o n

tion

ist

gegeben durch

B = Menge d e r

hinreichend

in

(x,r)

~ D

E]]9~ mit plied) rl xr2

<=> r :

rl prz

<=> r~ y r 2

Als

zweites

Die I n t e r p r e t a -

E~Dg~§,

S=B,

contains v

Beispiel

i n einem

riables

formalisiert.

:

rl

,

rl

:

(x,r)

: r ~Qg~§]]]

occurrence

~ A

sei

the defining

S

=

Das l i e f e r t

die

Identifikation

-Programm. folgende

(ap-

von

controlled

(x,s)

fehls, in

{~}),

va-

Ein Z~hlmechanismus o r d n e den im

Interpretation

in

~N

B = m ×(~u

der

x ,

a b l a u f e n d e n Proze~ a u s g e f U h r t e n P r o g r a m m b e f e h l e n f o r t l a u f e n d Z a h l e n zu.

r

r2 .

w~hlen w i r P ~1

bzw.

~ A

i n dem

sei x

s

( x , ) E D

s ei

fur

:

d i e Nummer des Be-

(angewandt)

ALLOCATE - B e f e h l s laufen

natUrliche

des Axiomensystems

x.

n

auftritt, d i e Nummer des

Bis

zum Durch-

des z u g e h ~ r i g e n FREE-Befehls s e i

m = ~ ,

dann werde

m = Nummer des

FREE-

Befehls gesetzt,

(nl,ml

~ y (n2,m2)

<=> nl > n 2 A ml ~ m2 ,

s p <=> n ~ s < m. (Dabei g e l t e

n < ~

fur

alle

Die I d e n t i f i k a t i o n s f u n k t i o n tation

gerade die

Anmerkun~ :

n E IN .) id

beschreibt

An den b e i d e n B e i s p i e l e n

sierung eigentlich

noch n i c h t

streng

Sin n e

Mengen

und

bar

statischen

interpretiert.

fikationssystem

i n der j e w e i l i g e n

Identifikationsvorschriften

B

S

e r k e n n t man, dab u n s e r e F o r m a l i -

genug i s t . werden b i e r

W o l l t e man ganz genau s e i n ,

a l s momentanen

Interpre-

i n den b e i d e n S p r a c h e n .

Ausschnitt

Die im m a t h e m a t i s c h e n dynamische v e r ~ n d e r mUBte man e i n

Identi-

im A b l a u f der P r o g r a m m e l a -

29

boration

auffassen

Folge

durch eine fehlende

und d i e

von d e r a r t i g e n

Genauigkeit

jedoch

Diskussion

der G r u n d b e g r i f f e

te Strenge

verzichtet.

4.

Reduktion

mud es s e i n , Beispiel

einer

Ausschnitten

keinen

EinfluB

hat,

haben w i r

Axiomatisierung

beschreiben.

auf die der

hier

Da d i e s e

beabsichtigte

KUrze h a l b e r

von i n t u i t i v e n

g e w i s s e i n der u n f o r m a l i s i e r t e n

auf

letz-

Vorstellungen

Theorie auftretende

beweisen .

aus den Axiomen zu

Wir w o l l e n

dies

Gesetz-

an einem

vorfUhren.

In gewissen Sprachtypen vorigen

Abschnitt

Grundbegriffe kann

im gesamten P r o g r a m m a b l a u f

yon G r u n d b e g r i f f e n

E i n e der A b s i c h t e n m~igkeiten

Identifikation

S

kann man, wie etwa an dem B e i s p i e l

zu s e h e n ,

B,S,y,p

die

auf

B

ALGOL 68

im

i n das A x i o m e n s y s t e m e i n g e b r a c h t e n und

y

reduzieren.

In

diesen

Sprachen

durch S = B

und

durch

p

spb <=> syb v definiert

werden.

Wir werden d i e s e die M~glichkeit Vorgegeben

sei

Sprachtypen

durch d r e i

der Begriffsreduktion ein

geeignetes

Identifikationsmenge Wir

s = b

X

weitere

mit

konstruieren~

(B,S,T,p)

.

Wie ] e i c h t

das

" s2

ersichtlich,

- kurz wir

ist

klasse

von

werde s,

durch s

"-"

~

-

eine

< = > [VbEB : s l p b df

d i e Menge d e r ~ q u i v a l e n z k l a s s e n Projektion

S

(B,S,y,p)

S von

.

leistet"

Relation

- wie folgt

wie :

<:> s2pb ] .

bezUglich

ausgedrUckt,

ein Repr~sentant

eine

"dasselbe

eine Aquivalenzrelation. in

fur

neuer Axiome e i n B e r e i c h s y s t e m

gesagt

auf

Axiome b e w e i s e n .

(D,A)

~ber einem B e r e i c h s y s t e m

Dazu d e f i n i e r e n sl

dieser

Identifikationssystem

k~nnen nun z u n ~ c h s t ohne H i n z u f ~ g u n g

(B,S,y,~)

Axiome a u s z e i c h n e n und

Hilfe

d.h.

~ .

~ , ~

Es s e i

die

sei

kanonische

die ~quivalenz-

3O

Weiter

definieren

wir

die

Relation

~

auf

~x B :

spb <=> spb . df Diese D e f i n i t i o n i s t

unabh~ngig vom s p e z i e l l e n Repr~sentanten

Lemma i

: (B,S,¥ ~)

i s t ein ~er¢ichsystem.

BeweCs

: Wir mUssen das Axiom ~b

s

von

(AO) v e r i f i z i e r e n :

A bTb' => spb A byb ~ => spb' => spb'

Es sei nun

(D,A)

dasjenige I d e n t i f i k a t i o n s s y s t e m f u r

(B,S,y,~) ,

das gegeben i s t durch : c Xx~ (x,~) E A-<= > [ ~ t e df

Lemma 2 : Das I d e n t i f i k a t i o n s s y s t e m

Beweis

: Wir mUssen das Axiom

dann g i b t net ist,

es

(y,t)

genau e i n

E A,

wobei

(x,b)

E D

es g i b t

genau e i n

(x,b)

S : T = T A (x,t) E A ].

(D,A)

ist

funktion,

sei

~

die

geeignet.

verifizieren.

T = ~,

Sei

und es g i b t ,

da

(y,s) (D,A)

~ A; geeig-

mit

~ D

L x , b => m t p b ~) , mit

x = y A spb A (b~E L x , b => ~ b ~ ) SchlieBlich

Uber

und

(At)

x = y A tpb A ( b ' ¢ d.h.

X

zum System

(D,A)

o

geh~rige

d.h. mit

=> m ~ b ' ) ] . i d ( y , ~ ) = ( x , b ) <:> [ x =y A ~pb A ( b ' ~ L x,b

Identifikations-

~.

31

Lemma 3 : FUr

(y,~)

EA

Der Beweis v e r l ~ u f t

und

~hnlich

(y,s)

tionsfunktion

(B,S,x,p)

weitere

Axiome f u r

= id(y,s)

leicht

.

einsichtig.

e i n e s neuen B e r e i c h s y s t e m s erhalten,

wie d i e

~sES

~bEB : spb

(A3)

Vb~B

~sCS

(A4)

VsES

:

dessen I d e n t i f i k a -

im u r s p r U n g l i c h e n

System.

das vorgegebene B e r e i c h s y s t e m

{b : spb}

ist

wohlgeordnet

(A3)

und

Aufbau von

Wir w o l l e n z e i g e n S

: spb A ( b ' y b = > ~ s p b ' )

(A2)

: Die Axiome

"sinnvollen"

und

i-d(y,~)

ein :

die Begriffsreduktion

B

leistet"

(A2)

Anmerkung nen

Konstruktion

Identifikationssystem

"dasselbe

Wir fUhren nun d r e i

gilt

wie bei Lemma 2 und i s t

Damit haben w i r a l s o durch d i e e i n neues g e e i g n e t e s

E A

B

und

entscheidende

sind S

triviale

verlangen.

aufeinander

y .

Axiome, d i e e i (A4)

ist

die fur

Forderungo

: Unter der V o r a u s s e t z u n g d i e s e r

bijektiv

bzgl.

abbilden

und

Axiome l a s s e n s i c h

~

durch

~x B

durch

y

charakteri-

sieren. Dazu d e f i n i e r e n

wir

eine Relation

T~-b < ~ (unabh~ngig

auf

spb A ( b ' T b = > ~ s p b ' )

vom R e p r ~ s e n t a n t e n )

Lemma 4 :

~

und beweisen

a)

~ES

~IbEB

: ~b

b)

VbEB

~,sES

: T~b

c)

Ist

~b*

,

so g i l t

:

:

s~b <=> b*Tb V b* = b . Beweis

a)

:

Existenz : Sei mit

spb .

sei

b, = b,

s

Repr~sentant von

~.

Wir k o n s t r u i e r e n eine Folge und f a l i s

es ein

b'

Nach ( A ~ ) g i b t es

bEB

F = { b , , b 2 , b s , . . . } c B.

g i b t mit

b'yb n

und

Es

spb' ~ so

32

sei

bn+ 1 = b ~.

]etztes

F

Element

ist

b*.

nicht

FUr

}eer

b*

~ b' Fo]glich

gilt

und

: Seien

spb2 ,

b,yb2

fUhrt bl

b)

wegen

(A4)

ein

und

: b ' T b A spb'

(A4)

mit

wegen

wegen

s~b,

b=yb, s~b2

s~b~

und

s~b2 .

Dann i s t

also

oder

folgt

b2yb,

b,,b2£B

nach

bIyb2 Aus

spb*

~b*.

Eindeutigkeit spb~

und b e s i t z t

gilt

oder

b,

der W i d e r s p r u c h

zum W i d e r s p r u c h

= b2 •

~spb~ ,

mspb2 .

ebenso

Daraus f o l g t

= b2.

Existenz

: folgt

Eindeutigkeit

:

Repr~sentanten b'£ B byb'

und oder

unmittelbar Seien sl

slpb'

(A3) .

sl,s~ES

und

s~

Wegen

b = b'

Umgekehrt z e i g t

aus

mit

gilt

dann

~1~b

In b e i d e n

man genauso

~1~b

gilt F~llen

und

s~pb

und

mb'yb ist

~2~b .

FUr d i e

s2pb .

und m i t

Sei

(A4)

dann aber auch

s2pb'

:

s2pb ~ => s l p b ' Insgesamt

hat man a l s o

fur

alle

slpb' Somit

c)

ist

Es g e l t e

sl

- s2

~b*,

b'E B :

<~=> s 2 p b '

und d a h e r

~I

= ~

•

also spb*

und

byb* =>mspb . Gilt

nun

s~b ,

so auch

spb~

und m i t

(Ad)

folgt

b y b * V b*yb v b* = b o Da

byb*

nach V o r a u s s e t z u n g

a u f den W i d e r s p r u c h

~spb

fUhrt,

nun

folgt

33

folgt

also b*yb v b* : b .

Die u m g e k e h r t e

R i c h t u n g der ~ q u i v a l e n z b e h a u p t u n g

Aufgrund dieses

Lemmas k~nnen w i r

mit der reflexiven

HUIIe

¥refl

nun e i n f a c h yon

¥

ist

S

trivial.

mit

B

und

gleichsetzen.

Die A b b i l d u n g f f(s) ist

:

surjektiv,

: S÷

mit

b <=> [spb A ( b ' T b = > ~ s p b ' ) ] df

und wenn w i r

das neue System

B

(D,~)

aus dem I d e n t i f i k a t i o n s s y s t e m

mit

c (X,B) (x,b) konstruieren, Satz

:

E A <=> [ ~ s ~ S df

so g i l t

Sei (D,A)

= b .

fur

X

schrieben Anschrift

und

kann a l s o (A4)

allein

f(s)

= b A (X,S)E A]

:

~b:r

id(x,b)

(A2) , (A3)

:

FUr d i e

fikationsfunktion

Die I d e n t i f i k a t i o n

und

schlie~lich

f(s)

(D,A)

zum I d e n t i f i k a t i o n s s y s t e m

(B,B,Y,Yrefl) id

gilt

= id(x,s) unter

geh~rige

Identi-

:

der

. Voraussetzung

durch die

Begriffe

B

der Axiome und

¥

be-

werden.

des V e r f a s s e r s

Technischen Universit~t

: Dr.Fred

KrUger,

Mathematisches

Institut

MUnchen, D-8000 MUnchen 2, A r c i s s t r a B e

21.

der

ZUR UBERSETZBARKEIT VON P R O G R A ~ I E R S P R A C H E N H. JURGENSE~

I. Einleitun~ Die erste Anregung zu den folgenden Uberlegungen zur Ubersetzbarkeit yon Programmiersprachen ergab sich aus Diskussionen im Zusammer~ang der Ausstattung des LISP-Systems f~r die ELECTROLOGICA X8 in Kiel mit einem Compiler. Das bis dahin rein interpretativ arbeitende LISPSystem war dem Rechenzentrum der Universit~t Kiel 1968 yon W. van der Poel

0 I~ zur Verf~gung gestellt und 1968-71 von F. Simon 0 6 ~ und dem

Verfasser ES] den Gegebenheiten der Kieler Anlage angepaBt und betr~chtlich erweitert worden.

1971-72 wurde der Compiler von B. Kal-

hoff C6] hergestellt und im wesentlichen im "bootstrap"-Verfahren implementiert. Bekanntlich stehen dem Bau eines Ubersetzers f~r das vollst~ndige LISP einige prinzipielle Hindernisse im Wege; Gblicherweise werden diese dadurch umgangen, da~ die Sprache fGr den Dbersetzer eingeschr~nkt wird [2,6,7,12,14,15] . Ist dieses Vorgehen auch unsch~n, so wgre es noch tragbar, wenn die Einhaltung der Einschr~nkungen zum Zeitpunkt der Ubersetzung, sp~testens aber zum Zeitpunkt der Rechnung GberprGfbar ware; fGr LISP ist dies in einigen F~llen grunds~tzlich u r ~ g lich. Wit wollen diese Aussage im folgenden pr~zisieren. Es wird sich zeigen, da~ die Schwierigkeiten allein auf Akzidenzien yon LISP zurNckzufNhren sind, die die Sprache allerdings erst programmiergerecht machen. Dadurch wird die Frage nach einem generellen Verfshren nahegelegt, mit dessen Hilfe beim Entwurf einer ~hnlich LISP universellen Programmiersprache diese Probleme vermieden werden k~nnten. Insofern sollten im weiteren die aus LISP herangezogenen Beispiele nur als Erl~uterungen der allgemeineren Situation verstanden werden. 2. Spezifische (jedoch behebbare)Probleme

eines LISP-Compilers

Von den bei der Konzeption eines Compilers fGr LISP auftretenden spezifischen Problemen lassen sieh einige unter Verzieht auf Rechengesehwindigkeit vermeiden, andere durch geringfGgige Anderungen in der "Implementationsvorschrift" des EVAL-APPLY-Zyklus [7] beseitigen

35

•

8 • Es handelt , 9sich

mit

,

1

3

•

dabei durchweg um Fragen im Zusammenhang

(I) der Bindung freier Variabler, (2) der Kommunikation zwischen interpretierten compilierten Funktionen

und

und

(3) der m~glichen unterschiedlichen "Typenvereinbarung" (CSET, DEFINE~ DEFPROP, RE~PROP usw.) zum Compilations- und Rechenzeitpunkt.

Im einzelnen vergleiche

man dazu Saunders

~4~

, S. 70 f. Die Schwie-

rigkeiten entstehen, well (I) die in LISP vorgeschriebene Variablenbehandlung eine einfache und effektive Kellerspeicherungstechnik im compilierten Programm verbietet und

(2) die Unsicherheit ~ber die aktuelle "Typenvereinbarung" aufwendige Tests zur Rechenzeit erforderlich macht.

In den bestehenden Cempilern wird meist unter Verzicht auf vollstindige Korrektheit eine LSsung vorgezogen, die sehr viel schnellere Objektprogramme

zuii~t

[6,7,10,12,15~

. Da sich die genannten Problem%

wenn auch unter Effektivit~tsverlusten, beseitigen lassen, wollen wir diese Fragen im folgenden ausklammern und insbesondere in allen Beispielen voraussetzen,

dab eine entsprechend bereinigte

LISP-Version

mit idealem Compiler benutzt wird. 3. Sich selbst ~ndernde Programme Sehr viel komplizierter

als die bisher aufgez~hlten

Probleme

der sich zur Rechenzeit

selbst ~ndernden Programme;

solche Programme

sind in LISP formulierbar, "ALGOL Y" [I~ vorgesehen.

ist das

aber auch z.B. in der Konzeption yon Wir wollen die Frage, wie welt es ~ n s c h e n s -

wert ist, sich selbst ~ndernde Programme zuzulassen, hier nicht diskutieren I). Es kom~t uns vielmehr darauf an, eine Reihe yon Forderungen herauszuarbeiten,

die man an eine Progrsmmiersprache

mit sich

selbst ~ndernden Programmen om~d an ihren Compiler mindestens sollte, um zu erreichen, compilierbar"

da~ alle "compilierbaren"

sind. Dabei lassen wir die Frage der Okonomie

pilers und der Objektprogramme Die Korrektheitsforderung wie m~glich:

f~r den Compiler formulieren wir so schwach

(Interpretation),

eine Funktion zuordnet.

des Com-

vorerst v~llig auger acht.

Es seien LI, L 2 Programmiersprachen,

ij eine Abbildung

stellen

Programme'~orrekt

Ein Compiler

die jedem Programm(text)

p6Lj

(partielle Abbildung)

c: L I --~ L 2 heine korrekt, w e ~ m (I) Quelle(c) in ~! entseheidbar I) Zu allgemeinen Komplexit~tsfragen Buchberger [4] .Zu Realisierungen

und fur j = 1,2 sei

ist

in diesem Zus~mmerahang v~l. f~r ALGOL vgl. ~17,18,19].

56

und

(2) fur alle p@Quelle(c)

gilt:

(a) Quelle(i2(c(p)))--_~

Quelie(i1(P))

~X e Quelle(i2(c(p))): und

(b) Quelle(i2(c(p)))

und

i2(e(p))(x) = il(P)(X)

ist in Quelle(i1(P))

Wir fordern also, da2 die Nicht-Compilierbarkeit

entscheidbar.

eines Programmes zu

einer Fehlermeldung f~hrt (I); wir lassen zu, da2 die durch den Objektcode definierte Funktion Einschr~nkung der durch das urspr~ngliche Programm definierten Funktion ist (2a~ und begn~gen uns damit, da2 wir diesen Unterschied eventuell erst zur Rechenzeit meldungen)

(durch Fehler-

erfahren (2b).

Die sich selbst ~ndernden Programme klassifizieren wir in solche mit expliziter Anderung (z.B. durch Deklaration) und solche mit impliziter Anderung (durch Textsubstitution).

W~hrend erstere einem Compiler

keine prinzipiellen Schwierigkeiten bereiten d~rften, m~ssen b e i d e r zweiten Klasse in der Definition der Semantik der Programmiersprache Vorkehrungen getroffen werden, um eine, worm aueh noch so un~konomische, nicht-triviale

Compilierbarkeit

zu erreichen.

3.1. Explizite Anderungen In LISP k6nnen explizite Programm~nderungen DEF~OP,

zur Rechenzeit

durch

DEFINE r CSET und ~hnliche Fumktionen durchgef~hrt werden.

Statisch entsprechen diesen beispielsweise in ALGOL 60 die Deklarationen. Explizite Programm~nderungen werden allgemein durch Anweisungen zustande k o ~ e n m~ssen, die aus (I) einer Definitions- odor Execute-Anweisung (XEQ), (2) dem Namen des zu definierenden Programmteiles und (3) dem definierenden Ausdruok bestehen. In der Terminologie yon ALGOL 60 k ~ e n grammteile

sicher Prozeduren,

als ~nderbare Pro-

eventuell aber auch Typenvereinbarungen

und Anweisungen mit ~arken in Frage. Beispiel I: DEF~ROP (BI

(L~BDA (...)

(...(DSFPROP (GSNS~) ( . . . ...))

(QUOTS SXP~))

EXPR)

sl

(...)

Ein derartiges Beispiel stellt fiat elm Compiler-orientierte s LISP-

37

System kein Problem dar; dabei ist es gleichgiiltig, ob der Compiler nach der Funktionsdefinition

innerhalb yon BI explizit aufgerufen

wird oder DEFI~OP die Compilation Gbernimmt. Definitionen global wirksam.

In LISP sind DEFPROP-

In Programmiersprachen mit statischer

Blockstruktur entsprechen der Funktion DEFPROP meist die Deklarationen; Neudefinitionen mG~ten also nur lokal wirksam sein. Das Beispiel s~he in einer solchen Sprache etwa folgenderma~en aus: begin ~ t y p e ~ procedure BI (...); begin

begin computed ~ t y p e ~ procedure

(GENSY~.~; ... ) ;

en___dd;

end;

o

end Daraus ergEben sich f~r einen Compiler keine besonderen Schwierigkeiten; selbstverst~ndlich m~Bte er zur Rechenzeit aufrufbar sein; ferner m~Bte er rekursive Aufrufe zulassen, um Deklarationen von (computed procedure, s

innerhalb des den Rmpf einer
defi-

nierenden Textes verarbeiten zu k~nnen. In vielen FEllen k~nnte es erv~dnscht sein, eine in einem ~u~eren Block deklarierte Prozedur in einem inneren Block neu, Wirknng, DEFPROP).

zu definieren

(dies entspr~che

jedoch mit globa!er

der globalen Wirkung yon

Einen sonst idealen Compiler vorausgesetzt,

verhEltnism~Big einfach durch grunds~tzliche nen und Definition erreichenl); z.B.:

lieBe sich dies

Trennung yon Deklaratio-

I) Damit w~rden auch die in manchen Programmiersprachen (wie ALGOL 60) existierenden Unterschiede in der Behandlung yon (identifier~ s als Prozedurnamen und als sonstige Variablen-Namen beseitigt.

38

be~in list L; o

o o a

begin name X; for X & L do declare qomPuted procedure X;

be~in for X @ L d_.odefine computed

~roeedure(X;

...);

o o e

en___dd;

endi

eA

In diesem L~sungsvorschlag ist (~hnlich wie in LISP) nicht einmal mehr die Anzahl der dynamisch definierten Prozeduren statisch festgelegt. An der Compilierbarkeit derartiger zur Rechenzeit explizit ge~nderter Programme ~ndert sich auch nichts, wenn man wie im Beispiel 2 Rekursivit~t zuliBt. Beispiel 2: DEFPROP (A2 (L~BDA

(...) (...(~a ...(B2 . . . ( ~ •..(~...)...)...(@

...)...) ...))

C

EXPR) DEFPROP (B2 (L~,~BDA (...) (...(DEFPROP (QUOTE A2) (...) (QUOTE EXPR))...))

{ ExP FEXPR

A2 ( . . . )

})

39

Die vier Aufrufe yon A2 werden wie folgt bearbeitet: (a) Ursprdngliche Definition von A2. (b) (I) Falls B2 ~[PR ist: Urspr~ngliche Definition von A2. (2) Falls B2 FEXPR ist: In Abh~ngigkeit vom Zeitpunkt der Auswertung in B2; bei mehrfacher Auswertung also eventueli verschieden. (c,d)

Umdefinierte Version yon A2.

Dies ergibt sich fur (a) aus der Festlegung, dab bei Aufruf einer Prozedur F zuerst in F eingetreten wird und dann die aktuellen Parameter bestimmt werden. (bl) aus dem "call-by-value"-Prinzip. (b2) aus dem "call-by-name"-Prinzip. (c,d) aus der Festlegung, dab Arguments nacheinander yon links nach rechts bestimmt werden. (b,c,d) machen auch bei Benutzung eines Compilers keine Schwierigkeiten,

(z.B. in DEFPROP)

falls bei der Berechnung der Argumente

dieser

Aufrufe keine weiteren Anderungen der Definition yon A2 erfolgen (sonst Behandlung entsprechend

(a));

(c,d) sind auch dann unproble-

matiseh, wenn sine andere sinnvolle Reihenfolge

der Argumentsmswertung

festgelegt wird, sofern das Beispiel dann ~berhaupt

ein zul~ssiges

Programm ergibt. Wegen (a) muB v o n einem Compiler-orientierten gefordert werden,

System

da~ Ob~e_kpKo~r~m~e_g~keller% und eventuell von einem

'lgsr~a[e collector" mitbehandelt werden I). 3 ~ 2 - I m p l i z i t e Anderungen Implizite Programminderungen Programmtextes

kommen dadurch zustande,

da~ Teile des

ohne ausdr~ckliche Neudefinition ihrer Einbettung in

den Kontext ausgetauscht werden (z.B. durch Anderung des Textes einer Prozedur ohne erneute Deklaration);

dazu ist notwendig und hinreichend,

dab es mSglich ist~ (I) den Program~text des ausgef~hrten Programmes zur Rechenzeit zu srreichen und

(2) Textst~cke ohne Beeinflussung des Kontextes zu ersetzen.

In LISP erreicht man (I) durch GET bzw. ASSOC oder iquivalente Funktionen oder durch (explizite) Programm~nderungen zur Rechenzeit (in LISP X8 auch durch Einlesen) und

(2) durch RPLACA, RPLACD und abgeleitete Funktionen.

I) Bei LISP ist fur die Kellerung speziell zu beachten, Umdefinition yon A2 in B2 global wirksam ist.

dab die

4O

Geht man davon aus, dab die Operationen wie RPLACA und RPLACD auf Objektcode angewendet ten Programm~nderungen,

werden k~nnen,

nicht

so w~ren diejenigen implizi-

bei denen der zu ~ndernde Text mit GET oder

ASSOC erst nach der Compilation aufgesucht

werden soll, unkritisch,

sofern - wie Gblich - der ursprttugliche Programmtext lierung vergessen werd~n dGrfte

I) .

nach der Compi-

Diese v e r h ~ l t n i s m ~ i g

einfache

L~sung ist jedoch in den Gbrigen F~llen impliziter Anderungen meist nicht anwendbar.

Typiseh ist das folgende

Beis~iel 3: DEFPROP

(D3 (LAA~BDA ( . . . )

(SETQ

V3

(PROG (V3 X3 Y3 . . . )

(LIST

...))

(SETQ X3 (LIST ...)) (SETQ Y3 (LIST ...)) (DEFPROP (QUOTE A3) (LIST (QUOTE L ~ B D A )

V3 (APPEND X3 Y3))

(QUOTE EXPR)) (CSETQ B3 Y3) ® m o

>) EXPR )

D3 ( . . . ) Der k r i t i s c h e P u n k t i n d i e s e m B e i s p i e l i s t , da~ d i e i n D3 neu d e f i n i e r t e F u n k t i o n A3 und d e r Wert v o n B3 das T e x t s t d c k Y3 gemeinsam haben. Die Situation ist folgendermaSen:

f

.......

J

Jede T e x t s u b s t i t u t i o n i n B39 d . h . i n n e r h a l b Y3, i s t g l e i c h z e i t i g eine i m p l i z i t e A n d e r u n g y o n A3. Bei i n t e r p r e t a t i v e m Rechnen w i r d d i e s automatisch ber~cksichtigt. Durch Compilation wird die Textidentit~t yon A3 und B3 jedoch aufgehoben: Anderungen yon B3 wirken sich nicht mehr auf A3 aus. Fdr LISP bedeutet

das: Es gibt Programme,

die in compilierter und

I) Ist die Referenz des Programmes auf seinen Text bereits vor der Compilation im Programmtext realisiert ("zirkulire" S-expression), so kann der Compiler dies schon bemerken u. z.B. mit einer Fehlermeldung reagieren.

41

uncompilierZer

Version verschiedene

Funktionen

gibt keinen korrekten nicht-trivialen Das Beispiel ist jedoch keineswegs LiSP-Version

erseheinen mag;

darstellen;

oder: es

Compiler fdr LISP.

so unnatdrlich,

wie es in seiner

jede sinnvolle Realisierung

tes der s m~Bte etwa das folgende entspreehende Programm zulassen:

des Konzep-

dem Beispiel 3

begin strin~ X3, Y3;

X3: . . . . ; Y3: . . . . ;

be6in computed < t y p e >

~rqcedure

(GENSY~;

CONNECT(X3,Y3) ) ;

end;

end Wir sehen die folgenden zwei M~glichkeiten, beseitigen:

Verbot

3.2.1. Verbot

oder Explizit-Nachen

diese Schwierigkeiten

zu

impliziter Anderungen.

impliziter Anderun~en

Wir sahen, dab es kaum m~glich sein wird, Situationen wie in Beispiel 3 zu vermeiden, wenn man in sin~voller Weise die N~glichkeit zulassen will,

dab sich Programme

Ein Verbot

zur Rechenzeit

impliziter Anderungen

die Textmanipulation

(auch nur explizit)

keine Substitutionsoperationen

dieses ist sicher f~r manche Anwendungen 3.2.2. Explizit-Nachen

indern.

ist also damit gleiehwertig,

daS fdr

erlaubt werdenl);

ziemlich un~konomisch.

im~liziterAnderun~en

Das Problem des Beispiels 3 wird noch dadureh kompliziert,

daS die

inderungen yon B3 wihrend der Ausfdhrung yon A3 stattfinden k~nnen. Zur Zeit des Aufrufs yon A3 liegt also die Interpretation yon A3 als Funktion noeh nicht lest. Dies scheint

inkonsequent,

wenn man berSck-

I) Eine unkritische "Quasi-Substitution" U = (A B C) -->U = (A D C) ist in LIS2 auch ohne RPLACA/R~LACD z.B. mit (L~,~BDA (U D) (LIST (CAR U) D (CADDR U))) m~glich - allerdings mit gr~Serem Zeitund Speicheraufwand.

42

sichtigt,

da~ gleichzeitig normalerweise

die Parameter yon A3 endgGl-

tag ausgewertet werden (dies gilt nicht fur FEXPR's). Abhilfe bringt die folgende Festlegung zur Semantik: Der Prozeduraufruf F(X,Y,...) hat die Wirkung von f(X,Y,...); dabei ist f die durch den Ausdruck (Text) yon F zum Zeitpunkt des Aufrufs definierte Funktion. Die fur z.B. ~eomputed statement,s Festlegung sind evident I). FUr ein Compiler-orientiertes sequenzen:

n~tigen Nodifikationen dieser

System hat das u.a. die folgenden Kon-

(I) Auch nach der Kompilation muB der ursprGngliehe Programmtext

erhalten bleiben;

"Name-Prozedurtext"

die Zuordnung

bzw. "Name - Ausdruck" wird

fur das Programm selbst aufgehoben, fGr den Compiler bestehen;

bleibt aber

GET und ~hnliche Funk-

tionen erreichen den Text also nicht mehr. (2) Substitutionen im ursprGnglichen Programmtext mGssen registriert werden. (3) Vor AusfGhrung eines ProgrammstGckes

(Prozedur,

Anweisung) muB geprGft werden, ob es seit seiner letzten Compilierung ge~ndert wurd~ und eventuell neu compiliert werden. (4) Die verschiedenen Programmversionen im Quelleode und Objekteode mGssen gekellert werden. Ob sieh dies brauchbar durchfGhren l ~ t ,

h~ngt wesentlich v o n d e r

Realisierung von (2) ab. FUr LISP dGrfte das sehr aufwendig sein. 4. Konsequenzen f~r ' LISP Die Forderungen yon 3.2.2. ergeben ungef~hr die folgende gegen ~7~ S. 70-71 ge~nderte Definition der Semantik yon LISp2): I) Interessanterweise reicht also die "copy rule" yon ALGOL 60 fur die Behandlung yon sieh selbst ~ndernden Programmen aus. $.auch 0 2) Nan beaohte die folgenden Eigenschaften von copy fur A r g ~ e n t e , die nicht S-expression sind: (a) Die Identit~t von Listenteilen wird aufgehoben, z.B.

(b) Auf " ~ e i s e n " z.B. fur

ist c o ~

undefiniert

(Pehlermeldungen);

43

evalq,uote[fn;args] = [ get[fn;FEXPR]v get[fn;PSUgR] --> eval[eons[fn;args];NIL]; T --> apply[copy[fn];args;NIL]] a p_p_~[fn;args;a] = [ n u l l [ f n ] -->NIL;

~to~Efn] ~ [ getEfn;SUBR] --> [get[fn;EX~{] /%ehanged[expr] -->

g~t[r~;Exp~]

apply[eopyFexpr];args;a]; T ~ exeeute[subr;args;a]]; --> a p p l y [ c o p y [ e x p r ] ; a r g s ; a ] ;

T --> apply[eopy[edr[sassoe[fn;a;%[[];error[A2]]]]];args;a]];

eq[ear[fn];LABEL]--> apply[oopy[eaddr[fn]];args;oons[eons[cadr[fn]; eaddr[fn]];a]]; eq[ear[fn];FUNARG] --~apply;copy[eadr[fn]];args;eaddr[fn]]; eq[oar[fn];~LMBDA] --> eval[eaddr[fn];noone[pa±r[eadr[fn];args];a]]; T --> apply[eopy[eval[fn;a]];args;a]] evalfform;a] = [ null[form] ~ NIL; numberpiform] --->form; atomIform] --~ [get[form;APVAL] --~carIapval]; T -->cdr[sassoe[form;a;~[[];error[A8]]]]]; eq[car[form];QUOTg] --~ eadr[form]; eq[ear[form];FUNCTION] --~ list!FUNARG;eadrIform];a]; eq[ear[form];COND] --> eveon[edr[formJ;a]; eq[carFform];PR0O] -~ progiedr!form];a]; atom[car[form]] --->[ get[ear[form];SUBR] -~ ! get[ear~form];EXPRJ A ehangedIexprl -~>apply[eopyiexpr]; T --> e x e e u t e [ s u b r ; e v l ± s [ e d r [ f o r m ] ; a ] ; a ] ] ; get[ear[form];FSUBR]---~ a

7

list[edr[form];a];a]; T--~ exeoute[fsubr;edr[form];a]]; get[car[form];EXPR] -~> apply[copy[expr];evlis[cdr[form];a];a]; get[carIform];FEXPR] ~ apply[copy[fexpr];list[edr[form];a];a]; T --> eval[cons[cdr[sassoo[ear[form];a;~[[];error!Ag]]]];

44

Literatur: [i] ALGOL-Bulletin: 21.1 (1965), 22.3.10 (1965). [2] Asai, K., und Inami, Y.: Implementation of LISP-Compilers (japaniseh). J. of the Inform. Processing Soc. of Japan ~, 253-260. Engl. Zusammenfassung in: Inform. Processing in Japan ~,I03 [3]

[4]

[5] [6] [7] [8] [9]

(1969). Berkeley, E.C., und Bobrow, D.G., (Hrsg.): The Progra~ming Language LISP: Its Operation and Applications. MIT Press, Cambridge, Nass., 1967 (3. Aufl.). Buchberger, B., und Roider, B.: A Study on Universal Functions. Inst. f. Numer. ~ath. u. Elektron. Inform.-Verarb., Universit~t Irmsbruck, Bericht Nr. 72-5, 1972. (J~rgensen, H.): LISP X8 - KIEL. Rechenzentrum der Universit~t Kiel, Dokumentation X8.22-I, 1970. Kalhoff, B.: Ein Compiler fur das System LISP 1.5 X8 KIEL. Diplomarbeit, Kiel, 1972. McCarthy, J., und andere (Hrsg.): LISP 1.5 Programmer's Nanual. NIT Press, Cambridge, Nass., 1966 (2. Aufl.). NcCarthy, J.: A New Eval ~unetion. NIT, Project MAC, A.I.Nemo 34. Moses, J.: The function of FUNCTION in LISP. SIGSAN Bull. 15,

13-27 (1970). [10] PDP-6 LISP (LISP 1.6). NIT, Project ~&~C, A.I. Memo 116A (1967). [ii] (van der Poel, W., und andere): PTT LISP-Interpreter voor EL X8. Dokumentation 1967-68. [12] Quam, L.H., und Diffie, W.: Stanford LISP 1.6 Nanual. Stanford Artif. Intellig. Lab., Operating Note 28,7. [13] Sandewall, E.: A Proposed Solution to the FUNARG Problem. Uppsais Univ., Department of Comp. Sc., Rep. 29 (1970). [14] Saunders, R.A.: LISP - On the Programming System. [3], 50-72. [15] Saumders, R.A.: The LISP System for the Q-32 Computer. [3], 220-238 und 290-317. [16] Simon, F.: Sekund~rspeicher in LISP. Diplomarbeit, Kiel, 1970. [17] Buchberger, B.: An Extension of ALGOL 60. Comm. Joint Inst. Nucl. Res. E5-5787, Dubns, 1971. [18] Busse, H.G.: Eine m~gliche Erweiterung der Programmiersprache ALGOL. Elektron. Rechenanl. ~, 81-83 (1966). [19] Kalmar, L.: Ist ALGOL wirklich sine algorithmisehe Sprache? In: D~rr, J., und Hotz, G., (Hrsg.): Automatentheorie und formale Sprachen. Bibl.lnst., Nannheim, 1970. Anschrift des Verfassers: Dr. Helmut J~rgensen, Mathematisches Seminar der Universit~t Kiel, D-2300 Kiel I, OlshausenstraBe 40-60.

fiBER DIE

SYNTAX

I. KUPKA

Summary:

UND

VON

DIALOGSPRACHEN

N. WILSING

A dialog is the interactive analogon of a program. The syntactical

structur of dialogs consisting of free ~nputs and input-dependent outputs is represented by means of a local syntax for describing these units and a global syntax describing their global connection in a dialog. The external form of the input syntax is a hierarchical syntactical partition of the whole set of input words. Considerations on the consistency yield additional conditions for the local syntax. Detailed examples explo~2n the method of syntactically describing conversational languages. I. Synta X und Kontextabhgn$iskeit der Einsaben Die Besehrei~ung von Dialogsprachen erfolgte bislang meist in enger Anlehnung an die Beschreibung von Programmlersprachen, z.B. unter Angabe einer Grammatik so dab die von

G

erzeugte Sprache

L (G)

G,

im wesentlichen die syntaktisch korrek-

ten Eingabezeilen enth~It. Im allgemeinen ist jedoch die syntaktisehe Korrektheit einer Eingabezeile abh~ngig v o n d e r Dialogvergangenheit, d.h. vom aktuellen Zustand des Systempartners. Dabei handelt es sich zun~chst um Kontextabh~ngigkeiten, wie sic auch bei Programmiersprachen fHr Stapelverarbeitung auftreten, etwa im Zusammenhang mit expliziten oder impliziten Deklarationen. Dar~ber hinaus muB man oft mehrere Klassen yon Systemzust~nden unterseheiden, derart dab die Zugeh~rigkeit zu verschiedenen Klassen gleichbedeutend ist mit einer unterschiedlichen Struktur der syntaktisch korrekten Eingaben. Dies ist z.B. der Fall, wenn die Dialogsprache einen sog. Modus der direkten und einen sog. der indirekten AusfHhrung besitzt und der jeweilige Modus vom Zustand abh~ngt. So besteht naeh ErSffnung einer Funktionsdefinition in

APL\360 durch

V F X

ein Zustand der indirekten Ausffihrung

(definition mode), in dem z.B. nieht alle mit

')'

beginnenden Kommandos gegeben

werden dfirfen, siehe Falkoff [2] . Andererseits sind jetzt Verzweigungen mit dem C~TO-Pfeil

' ÷ ' erlaubt, die im Modus direkter Ausffihrung nicht korrekt sind.

Vorprogrammierte Unterbreehungen yon Funktionen oder Prozeduren k~nnen zu Systemzust~nden w~hrend des Dialogs ffihren, in denen die Syntax der korrekten Eingaben zus~tzliehen Einschr~nkungen unterworfen ist oder vSllig neu definiert ist. Nach Aufruf der

APL\360-Funktion

46

VF

D]

0

÷

~+o

V sind z.B. auger der Bet~tigung der Unterbrechungstaste nur solche Eingaben korrekt, die einen Operanden des dyadischen Additionsoperators beschreiben. Naeh Aufruf der Funktion VG

v wird jede Eingabe auBer

OUT

(~bereinander getippt) als Text interpretiert und

wieder ausgegeben. Es liegt also eine vSllig vergnderte syntaktische Situation vor. Das letzte Beispiel zeigt zugleich einen Fall) in dem keine syntaktisch inkorrekten Eingaben auftreten kSnnen. Aber auch sonst spielen die syntaktisch i~korrekten Eingaben im Dialog - anders als syntaktisch inkorrekte Programme im Bereich der Programmierspraehen - eine konstruktive Rolle, indem sie ebenfalls eine Fortsetzung des Dialogs ermSglichen. Eine Ausnahme bilden bier Systeme mit syntaktisch gesteuertem variablem Eingabealphabet wie etwa der Benutzereingaben dient digen Wortmenge

A"

DIALOG, siehe Cameron [1] . Die Syntax

daher allgemein der Unterteilung einer vollstgn-

~ber dem Eingabealphabet

mindestens in einen durch eine Grammatik

A

in syntaktlsche Typen, und zwar

G l erklgrten Tell

II=L(GI) und dessen

Komplement

I = A" - I] . Dabei sind Eingaben aus I ebenso zu verarbeiten, z.B. o o zweeks Erzeugung einer Fehlermeldung oderAufforderung zur Korrektur, wie Eingaben

aus

I 1 . Da alle Eingaben den Systemzustand beeinflussen k~nnen und damit auch

dessen syntaktische Auswirkungen, ergibt sich eine weitere syntaktisehe Unterteilung der Eingaben im Hinblick auf diese Wirkung. Im Modus direkter AusfHhrung (execution mode) haben wit z.B. in

APL\360

die syntaktische Zerlegung

A~ = loV 11 v 12 ) I 1 = L(G|), wobei

12 = L(G2) )

G| die korrekten Eingaben zur unmittelbaren AusfHhrung und

G 2 die modusver-

~ndernden Kopfzeilen von Funktionsdefinitionen beschreibt. Es k~nnen auch syntaktische Unterteilungen auftreten, die durch Grammatiken

G|, G 2 mit

L(G I) ~ L(G 2)

beschrieben werden. Hierauf wird bei der nachfolgenden Analyse der syntaktischen Globalstruktur n~her eingegangen werden. Die so skizzierte Unterteilung von

A" variiert in Abhgngigkeit vom Systemzustand,

wie oben an Beispielen erl~utert. Zu jedem Zustand

S

fassen wir die dutch

Grammatiken beschriebenen Eingaben mittels einer vereinigten Grammatik

G(S)

47

zusammen und definieren als Menge der regulgren Eingaben: Iregul~r (S) = L abgelegt. In einem sp~teren Zustand

Sdirekt im Modus direkter Ausf~rung werde die abgelegte Eingabezeile duroh

einen Aufruf Do



odor mittels einer semantisch dazu ~quivalenten Formulierung zur AusfHhrung gebracht. (Zum Step-Part-Konzept, auf das bier Bezug genommen wird, siehe Smith [~.) Offenbar muS man im Zustand

Sindirekt alle solehen Eingaben als syntaktisch

regul~r ansehen, zu denen es einen auf

Sindirekt mittelbar folgenden Zustand

Sdirekt gibt, in dem diese Eingaben, wenn sie direkt gegeben werden, syntaktisch regul~r sind. Dem kann dureh L (G

(Sindirekt)

)

=

Am

Reehnung getragen werden. In der Praxis w~rde dies die Verschiebung der syntaktischen Analyse auf den Aufrufzeitpunkt, mithin die Abspeieherung ungepr~fter Texte bedeuten. Im Fall e ( G (Sindirekt)) ~

A~

ist eine gr~bere syntaktische Analyse zumEingabezeitpnnkt erforderlich, der eine feinere syntaktische Analyse im Aufrufzeitpunkt folgt. Letztere hat jedoch nichts mehr mit der konkreten Syntax eines Aufrufs wie

Do



zu tun, sondern nur

noch mit der Semantik dieses Aufrufs. Wir bezeichnen Eingaben aus

L(G(Sindirekt))

als formal resulgr, solehe dem Komplement zugehSrigen als formal irresul~r. Beim Aufruf zerf~llt die Menge der formal regul~ren Eingaben entsprechend der Zugeh~rigkeit zu L(G(Sdirekt)) in aktuell resulgre und aktuell i rresulgre. F~r den Benutzer ist bei der Eingabe bereits die Kenntnis der aktuellen Regularit~t wiehtig, fHr das System einzig die formale. Hier haben wir einen Fall, in dem Benutzer und System sich an jeweils verschiedener Syntax orientieren.

48

2. Die syntaktisohe Struktur der Ausgaben Unter Ausgaben sind bei elnem Dialog nlcht nur programmlerte Wertausgaben sondern ganz allgemein alle Ante~le des Systems am Gesamtdialog zu verstehen. Bei den derzeitigen Sprachen findet man unter anderem (Ausgaben hier und im folgenden unterstrichen)

dutch Ausgabebefehle veranlaBte Wertbeschreibungen, Beispiele:

2.]46381 ANSWER = 2.14638!

Anfragen des Systems, Beispiel aus dem Sprachkonzept

VENUS, siehe

MatthewsETJ:

? PLEASE DEFINE WHAT THE VARIABLE "X" = Wiedergabe gespeieherter Zeilen, z.B. zwecks Korrektur durch den Benutzer, Statusmeldungen des Systems, z.B. STOPPED AT LINE 7, sowie Fehlermeldungen. In einem Dialog, in dem auch das System aktiver, wenn auch zumeist deterministisch reagierender Partner ist, etwa im Bereich des "Problem-Solving", mu8 die systemseitige Syntax dieselben internen Objekte besehreiben wie die benutzerseitige. Beide liefern dann externe Abbilder einer gemeinsamen internen abstrakten Syntax im Sinne yon Mc Carthy, siehe [8]. Verschiedenheiten b e i d e r benutzerseitigen Syntax einerseits und der systemseitigen andererselts ergeben sich aus den untersehiedlichen Aufgaben fgr beide Partner. Anders als bei der Eingabe brauchen bei der Ausgabe keine Komplemente berUcksichtigt zu werden. Entsprechend der zugrunde gelegten abstrakten Syntax k~nnen die Ausgaben durch mehrere Grammatiken, etwa eine fur Wertbeschreibungen, elne fur Fehlermeldungen usw., syntaktisch beschrieben und dadurch zu syntaktischen Typen zusammengefa~t werden. Dabei braucht der syntaktische Typ einer Ausgabe nicht eindeutig dureh den Text bestimmt zu sein. Zum Beispiel k~nnte der Text einer Fehlermeldung zugleich der Text eines auszugebenden Strings sein. Eine syntaktische Mehrdeutigkeit anderer Art liegt vor, wenn bei vorgegebenem Systemzustand und vorgegebener Eingabe der syntaktische Typ der Ausgabe nur semantisch determiniert ist. So wird man oft neben Wertbeschreibungen Fehlermeldungen erwarten mUssen, z.B. nach Eingaben wie Type

(sqrt (a + b - c)).

Es kann sein, dab eine Indeterminiertheit bezUglieh des syntaktisehen Typs der Ausgabe durch eine weitere Unterteilung der Eingabesyntax behebbar ist. Wir werden die Konsequenzen hieraus im Zusammenhang mit der syntaktisehen Globalstruktur erSrtern. Die syntaktische Beschreibung der Ausgaben dient sowohl der Orientierung des Benutzers Hber errelchbare bzw. zu erwartende Ausgaben als auch der Festlegung der

49

konkreten Ausgabesituationen ffir den Implementierer° Die Beschreibung des yon den Autoren entwickelten APL-Dialekts

HDL, siehe [4], enth~It z.B. unter anderem fol-

gende Regeln der systemseitigen Syntax ("# " bedeutet "neue Zeile"):

:=

I ~ <stop answer> l ~ <semantical error messase> I <sto~ answer> I<semantical error messase>

:= l~ ~ I ~ :=

I



=

:= <scalar constant> I l <matrix description>

:= NUMERICAL SCALAR = I STRING

~ LENGTH I

NOTHING IS NAMED WITH



<stop answer> := STOPPED AT LINE

of FUNKCTION

Hierbei kennzeichnet die Unterstreiehung, dab es sich um Zeichen b zw. Variable ("Nonterminals") der Ausgabe handelt. Dabei brauchen syntaktische Regeln ffir die Ausgabe, die zu syntaktischen Regeln der Eingabe isomorph sind, nicht explizit aufgeffihrt zu werden. So werden z.B. ffir , <scalar constant> , plizit die Regeln vorausgesetzt, die zu den fHr ,

im-

<scalar constant>,

erklgrten isomorph sind.

3. Lokale und globa!e Syntax Die Eingabe- und die Ausgabesyntax strukturieren zwar wechselseitig die Worte (d.h. %u~erungen jedes Partners) im Dialog, nicht jedoch den Dialog als Ganzes. Es wurde bereits erw~hnt, da~ die syntaktische Strukturierung der Eingaben vom jeweiligen Zustand abh~ngt. Das gleiche gilt ffir die Ansgaben. Der globale Zusammenhang des Dialogs ist nun umso dentlicher beschrieben, je genauer die Abhgngigkeit der m~glichen syntaktischen Typen fHr Ein- und Ausgaben von den vorhergehenden syntaktischen Typen dargestellt wird. Erlaubt die Sprache z.B. Ausgaben zweier verschiedener syntaktischer Typen als1~aktion auf Eingaben eines syntaktischen Typs und kann diese Indeterminiertheit syntaktiseh beseitigt werden, so kann dies eingabenseitig zu Grammatiken

G] und

G 2 ffihren mit

n~mlich wenn eine Ausgabereaktion genau auf Worte aus

L(GI) ) L(G2) ,

L(G I) ~ L(G2) folgen k~nnen.

5O

Wegen der Problematik der Konstruktion von Grammatiken f~r relative Komplemente vgl. hierzu den Zusammenhang zwisehen $prachklassen und Komplementen bel Maurer [6J, S. 63, - geben wir daher als allgemeine Form einer lokal~ doh. bei festem Zustand, gHltigen Eingabesyntax die einer sog. ~estaffelten svntaktischen Partition an mit Gran~natiken

GI, .... , Gn, so da~ ( A = Eingabealphabet

I.

L(G i)

<

A~

2.

L(Gi)

# m

L(Gj)

3.

,

~]

~ ~

=

L(G~)

)

i = 1,2,...,n

L(Gi) oder L(Gj) oder 0

#

i = 1,2,..°,n J = 1,2,..~,n

L(G i)

J

e(gj)

(

e(Gi)

#

j = l,...,n i = o,...,n

, wobei

L(G o) ~

A~

sei.

Die syntaktischen Typen sind dann durch die Wortmengen ii

=

L(Gi)-

~ L(Gj)

L(Gj) <

L(Gi)

j = l,~..,n beschrieben. Die

i = O,l,...,n, bilden gerade eine Partition yon

li,

A ~ in dis-

junkte Mengen, siehe [3] . Die Mengen

L(Gi) , i = O,l,.o.,n

erscheinen nun im allgemeinen Fall als Vereinigung

disjunkter syntaktiseher Typen. Ein einfaehes Beispiel:

L(G 1)

iO I1

12 = L(G 2)

13 = L (G 3)

mit folgenden Grammatiken: G! :

<expression> :: =

:: =

:: =

= <expression>

I +

I I ?

51



:: = alb )'cid~~elfiglhlilj

:: = 01|121314i516171819 G2 :


input> :: = = ? +

I

= + ? G3 :

wie bei G i



:: =



= ?

Bei diesem Beispiel wird davon ausgegangen)

da~ Eingaben aus

i!

Zuweisungen be-

deuten, auf welche eine leere Ausgabe oder eine semantische Feh!ermeldung de~ Eingaben aus

12

folgt,

Zuweisungen bedeuten, welche RHckfragen des Systems bewir-

ken, auf die mit Eingaben aus

~.]

zu antworten ist, und dab Eingaben aus

13

Wertausgaben hervorrufen. Die Bildung relativer Komplemente macht bei Verwendung einer Backus-Notation EinfHhrung eines zus~tzliehen Symbols erforderlich. G!

und

<s2> das von

als Ableitungsregel

:: =

<sl>

-

<s2>

fHr die im Komplement liegenden Worte verwenden: von

<s2> ableiten.

A

< c >

ab) die sich yon <s|> ~ nicht

(Vgl. die Metaspraehe der Beschreibung yon HDL) [4] ,

S. 9). Zur Darstellung des Globalzusammenhangs des Dialogablaufs

die

<si> das Startsymbol yon

O2, so k~nnen wir

leiten sich alle Worte Hber dem Basisalphabet aber yon

Ist

erforderlich~

im Dialog ist eine Formalisierung

Hierzu eignen sich unendliche initiale Mealy-

Automaten mit A~

als Eingabemenge

B~

als Ausgabemenge

einer Zustandsmenge

(A = Eingabealphabet), (B = Ausgabealphabet), E

totalen Abbildungen o : A~ ×

E ~ ~

T : A ~ × ~ ÷ B~

und einem Anfangszustand

SO .

Der Zusammenhang zwischen einer Folge tierenden Folge

BI,B2,..,B k

AI, A 2 ) . . ) ~

von Eingaben und der resul-

von Ausgaben mit Start beim Zustand

SO

ist dann

durch

gegebeno

Si

= ~

(A i, Si_ ])

,

i = !,...,k-I

Bi

= T

(Ai, Si_ i)

,

i = 1,...,k

Siehe hierzu die ausfHhrliche Darstellung in

ziehung gegenseitiger Unterbrechungen beschreibbar durch die Folge

f3]

, wo auch die Einbe-

erSrtert wird. Der Dialog ist dann formal

A! 3! A 2 B 2 ,o.., An nB . Mit jedem Zustand

S ~

52

verbinden wit eine sog. aktuelle lokale Syntax bestehend aus den Gran~matiken G!,...G n

einer gestaffelten syntaktischen Partition f~r die Eingabe und einer Kol-

lektion yon Grammatiken GI,... , G 1.

L~i)

2.

C B~

T(A', S)

fHr die Ausgabe, welehe den Bedingungen

, i = !,...,m m ~J

6

L(Gj)

j=1 genHgt. %quivalenten Zust~nden werde dieselbe aktuelle lokale Syntax zugeordnet. Die Kollektion aller in einer aktuellen lokalen Syntax auftretenden Grammatiken heiBe lokale Syntax der Dialogsprache. Dabei besehrgnken wir uns auf den Fall endlicher soleher Kollektionen. Jede lokale Syntax definiert eine wiederum endliche Menge syntaktiseher Typen fHr die Eingabe als Menge aller vorkommenden Komplemente =C L(Gi) , wobei

die Ausgabe als Menge aller tisehen Typen der Eingabe, e TA

bzw.

tB s T B

net. Zu

tA s T A

Zustand

S

mit

Is(G i)

S auf die eventuelle Abh~ngigkeit vom Zustand hinweist, und fHr L(G_j). T A TB

sei eine Menge yon Symbolen fHr die syntak-

eine solehe in Bezug auf die Ausgaben. Die dureh

eharakterisierte Wortmenge sei mit

gibt es also eine Grammatik w(t A) = Is(Gi)

und zu

W(tA)

bzw.

W(tB)

tA

bezeich-

G i in der lokalen Syntax und einen

tB e T B

existiert eine Grammatik

--IG"mit

W(tB) = L(G_i). Unter einer $1obalen Syntax einer Dialogsprache verstehen wir eine linkslineare Grammatik

G = (N,TAU TB,R,D) (N = Menge der Variablen, TAr T B = Basisalphabet, R = Re-

gelmenge I D = Startelement) mit folgenden Eigenschaften: I.

L(G) C (rA r B)

2.

x c (TA TB)~, tA E T A , tB c T B , x tAt B c L(G) => x E L(G)

3.

Zu jedem Dialog ein Wort

tA]

t]B

A! BI A 2 B 2 .... ~ tA2

t B2 .. . tk

mit A i s w (tA) , B i E w (t)

tkB

Bk

existiert

E L(G)

, i = 1,...,k •

Bei Vorgabe einer lokalen Syntax kann eine globale Syntax konstruiert werden mit Hilfe einer auf der Menge der Eingabefolgen zu definierenden'Partition mit Substitutionseigensehaft' im Sinne von Hartmanis und Stearns, siehe ~3], S. 57. Eine vorgegebene Dialogsprache ist im allgemeinen dutch verschiedene Kombinationen aus globaler und lokaler Syntax darstellbar. Je mehr syntaktische Typen die lokale Syntax vorsieht, um so mehr k~nnen die einseitig bestehenden Kontextabh~ngigkeiten zwischen verschiedenen Eingabeworten Uber die globale Syntax errant werden. Auf der anderen Seite darf aber die ~bersichtllchkeit der $1obalen Syntax nicht verlorenge-

53

hen. Man kann das aus lokaler und globaler Syntax bestehende System als eine zweischichtige Grammatik, vgl. Maurer [6] S.71, auffassen. Dabei kSnnen jedoch spezifisch interaktive Aspekte verlorengehen,

z.B. wird die semantisch bedingte Variation der

aktuellen globalen Syntax nicht erfaBt. Der Beschreibung des APL-Dialekts

HDL

liegt eine lokale Syntax mit 12 syntakti-

schen Typen zugrunde, die das folgende Aussehen hat: Benutzerseitige

lokale Syntax:

(Elemente yon

T A)

I. fur normale Eingaben im Modus direkter AusfUhrung:

regular-mode-O-statement

2. zum Einschalten des Modus indirekter AusfHhrung: mode-change-to-l-statement 3. f~r Antworten des Benutzers auf Fragen des Systems: regular answer 4. fur normale Eingaben im Modus indirekter AusfHhrung: 5. zum Einschalten des Modus direkter AusfUhrung: 6. relativ zu I. und 2. fehlerhafte Eingaben: 7. relativ zu 3. fehlerhafte Eingaben:

lokale Syntax:

mode-change-to-O-step

irregular-mode-O-statement

irregular answer

8. relativ zu 4. und 5. fehlerhafte Eingaben: Systemseitige

irregular - mode-l-statement

(Elemente yon T B)

I. fur regul~re Ausgaben und semantische Fehlermeldungen: 2. fur Syntaxfehler-Meldungen:

regular-mode-l-statement

output

~rror messase

3. fur Fragen des Systems: questio~ 4. leere Ausgaben:

em~,,ty

Globale Syntax yon

HDL :

Die Grammatik der globalen Syntax lautet G = ( {DIALOG, MODE-O, MODE-I, OPEN-MODE}~ T A ~ T B, R,DIALOG) wobei R

aus den folgenden Produktionen besteht:

I. DIALOG+MODE-O,

DIALOG

MODE-I, DIALOG

OPEN-MODE

2. MODE-O + 3. MODE-O ~ MODE-O

regular-mode-O-statement

output ,

MODE-O + MODE-O

irregular-mode-O-statement

error-message

MODE-I + MODE-O

change-mode-from-0-to-l-step

empty ,

OPEN-MODE ÷ MODE-O

regular-mode-O-statement

question

MODE-O + MODE-I

change-mode-froml-to-O-step

empty ,

MODE-I + MODE-I

regular-mode-

MODE-I+ MODE-I

irregular-mode-l-statement

MODE-O+ OPEN-MODE

regular-answer

output

OPEN-MODE+ OPEN-MODE

regular-answer

question

OPEN-MODE+ OPEN-MODE

irregular-answer

error-message

tatement

,

,

empty , error-message

,

, , .

54

Eine entsprechende Dokumentation yon Sprachen wie

APL\360, JOSS u.a. w~re mit ihn-

lichen Grammatiken mSglich. Eine weitere Anwendung besteht in der Gewinnung eines Rahmens fur spezielle syntaktische Probleme. So ergeben sich beim Entwurf yon Dialogsprachen Bedingungen an die syntaktische Strukturierung im Bereich der lokalen Syntax, die aus Forderungen nach Konsistenz, Effizienz, Kompaktheit der Notation und anderen resultieren. Das syntaktische Konzept yon

APL erweist sich als ein

Ansatzpunkt fur eine ErfUllung versehiedener solcher Forderungen. In ~5] wird hierzu yon den Autoren u.a. dargelegt, dab sich die gesamte benutzerseitige lokale Syntax von

APL-~hnlichen Sprachen im wesentlichen dutch zwei Ableitungsregeln darstellen

l~St, in denen sowohl verschiedene Datentypen als auch dialogrelevante Kontrollstrukturen auf formal gleiche Weise durch Metavariable erfaSt warden. Literatur: [I] Cameron, S.H., Ewing, D., and Liveright, M.: DIALOG: A Conversational Programming System with a Graphical Orientation, CACM, IO, No.6,pp. 349-357 (1967) [2] Falkoff, A.D., Iverson, K.E.: APL~\360 Users Manual, IBM (1968) [3] Kupka, I., Wilsing, N.: A formal framework for dialog languages, Ber. d. Inst. f. Informatik d. Univ. Hamburg, 2 (]972) ~] Kupka, I., Wilsing, N.: Syntax und Semantik de~Dialogsprachen-Konzepts HDL, Bar. d. Inst. f. Informatik d. Univ. Hamburg, 3 (1973) ~] Kupka, I., Wilsing, N.: An APL-based syntax form for dialog languages, "APL Congress 73", (Gjerl~v, P., Helms, H.J., Nielsen~ J., ads.) North-Holland, Amsterdam etc.,pp. 269-273 (]973) ~] Maurar, H.: Theoretische Grundlagen der Programmiersprachen, Theorie der Syntax, Bibl. Inst., Mannheim etc. (1969) ~] Matthews, H.F.: VENUS: A small Interactive Nonprocedural Language, "Interactive Systems for Experimental Applied Mathematics", (Klerer, M., Reinfelds, J., ads.), Academic Press, New York, London, pp. 97-1OO (1968) ~] Mc Carthy, J.: Towards a Mathematical Science of Computation, "Information Processing 1962", Proc. IFIP Congress 1962 (Popplewell, C.M., ed.) North-Holland, Amsterdam, pp. 21-28 (1963) ~] Smith, J.W.: JOSS-If: Design Philosophy, Am.Rev° in Autom. Progr., ~, 4, Pergamon Press, Oxford etc., pp. 183-256 (1970) m

Anschrift der Verfasser: Dr. Ingbert Kupka und Dipl.-Math. Norbert Wilsing, Institut fHr Informatik, Universitgt Hamburg, D-2000 Hamburg 13, SchlUterstra~e 70

D E F I N I T I O N UND I M P L E N E N T I E R U N G

EINES DIALOGSYSTEZS

H. R O H L F I N G

i. E i n l e i t u n 9

Die v o r l i e g e n d e A r b e i t d i s k u t i e r t einige E i g e n s c h a f t e n des D i a l o g s y stems KANDIS.

Das S y s t e m e n t s t a n d durch die F o r t f ~ h r u n g der in

[i]

v o r g e s t e l l t e n A r b e i t und w i r d auf der R e c h e n a n l a g e B u r r o u g h s B67OO des Informatik-Rechenzentrums

der U n i v e r s i t ~ t K a r l s r u h e implementiert.

Der Kern des D i a l o g s y s t e m s Daten- und K o n t r o l l s t r u k t u r e n

ist eine h~here P r o g r a m m i e r s p r a c h e mit

zur F o r m u l i e r u n g n u m e r i s c h e r und nicht-

n u m e r i s c h e r P r o b l e m e und mit M 6 g l i c h k e i t e n der u n m i t t e l b a r e n K o m m u n i kation

zwischen P r o g r a m m i e r e r und R e c h e n a n l a g e 0ber eine B e n u t z e r s t a -

tion. Das S y s t e m e r m ~ g l i c h t die i n t e r a k t i v e Definition, A u s f ~ h r u n g und M a n i p u l a t i o n yon Progranamen und ihre S p e i c h e r u n g als S e g m e n t e oder Moduln

in e i n e m A r b e i t s b e r e i c h .

A b s c h n i t t 2 gibt eine C h a r a k t e r i s i e r u n g der Titigkeiten, d i e s e m D i a l o g s y s t e m d u r c h f ~ h r b a r sind. A b s c h n i t t drei f u n d a m e n t a l e S y s t e m e i g e n s c h a f t e n

die mit

3, 4 und 5 d i s k u t i e r e n

zur V e r w i r k l i c h u n g dieser A u f g a -

ben, A b s c h n i t t 6 gibt einen U b e r b l i c k ~ber die D i a l o g s p r a c h e und Abschnitt 7 b e s c h [ f t i g t sich mit e i n e m I m p l e m e n t i e r u n g s m o d e l l °

2. A u r a @ b e n des Dialogs

Typische Aufgaben

des Dialogs sind:

i. die T i s c h r e c h n e r f u n k t i o n , 2. das i n t e r a k t i v e E r l e r n e n des P r o g r a m m i e r e n s , 3. die i n t e r a k t i v e E n t w i c ~ l u n g von Programmen, 4, die i n t e r a k t i v e A u s f ~ h r u n g yon Programmen, 5. der

(interaktive)

V e r k e h r mit dem B e t r i e b s s y s t e m

einer Rechenanlage.

Der B e g r i f f " T i s c h r e c h n e r f u n k t i o n ~' b e z e i c h n e t im a l l g e m e i n e n die F i h i g k e i t eines D i a l o g s y s t e m s ~

ein S p r a c h e l e m e n t - eine V e r e i n b a r u n g

oder eine A n w e i s u n g - u n m i t t e l b a r nach der E i n g a b e auszuf~hren,

babel

h a n d e l t es sich m e i s t e n s um kurze und einfach s t r u k t u r i e r t e P r o g r a m m i e r aufgaben.

56

Charakteristische Problemstellungen sind:

la. die Berechnung der Quadratwurzel einer Zahl: sqrt(7.5) lb. die Berechnung der ersten n Zweier-Potenzen: for i to n do write(i,2*~i): Ic. die L~sl~Ig

eines linearen Gleichungssystems.

In diesem Fall existiert oft ein Programm, If:n] real werte

das herangezogen wird:

:= >>n Koeffizienten des Gleichungssystems<<

gauss(n, werte)

Dem Begriff "Tischrechnerfunktion" wird im folgenden der Begriff "direkte Programmierung" bzw.

"Programmieren im Direktmodus" vorgezo-

gen. Die Speicherung von Programmen mit der M6glichkeit des sp~teren und wiederholten Ausf~hrens wird mit "Programmieren im Speichermodus" bezeichnet(siehe Abschnitt 4 und 5). Das in den nichsten vier Klassifizierungen auftretende Attribut "interaktiv" verdeutlicht die Rolle des Benutzers einer Rechenanlage:Im Gegensatz zum Stapelverarbeitungsbetrieb, der ihm eine passive Rolle zuordnet, wird er in der Dialogprogrammierung in den ProzeS der Programmierung unmittelbar einbezogen. Es findet ein fortlaufender Informationsaustausch zwischen den Programmen des Benutzers und ihm selbst tiber Benutzerstationen

("Konsolen")

statt, der es ihm gestattet, auf

bestimmte Ereignisse sofort zu reagieren. Das interaktive Erlernen des Programmierens beginnt im allgemeinen mit Aufgabenstellungen, die charakteristisch fur die direkte Programmierung sind. Erst sparer wendet man sich umfangreicheren Problemstellungen zu, die in Abschnitt 4 und 5 angesprochen sind. In jedem Fall ben6tigt der Programmierer Hilfsmittel zur Formulierung von Programmen, zur Erkennung und Korrektur syntaktischer und semantischer Fehler und zur Uberwachung yon Programmausf~hrungen. Es gibt unterschiedliche Theorien dar~ber, wie Programme und Programmsysteme entwickelt werden sollen. Allgemein anerkannte Methoden sind "strukturiertes Programmieren" position durch Verfeinerung"

[2] mit "schrittweiser Programmkom-

[3], "modulates Programmieren"

"hierarchische Programmstrukturierung"

[4] und

[5].

Diese Programmiermethoden finden besondere Bedeutung in der interaktiven Program~ierung, sofern hier

57

a. die Definition,

die A u s f ~ h r u n g und das T e s t e n von u n v o l l s t ~ n d i g e n

P r o g r a m m t e i l e n m ~ g l i c h ist und der P r o g r a m m i e r e r i n t e r a k t i v zur V e r v o l l s t ~ n d i g u n g b e i t r a g e n kann. b. die Z u s a m m e n s e t z u n g von P r o g r a m m e n aus schon v o r h a n d e n e n P r o g r a m m e n m ~ g l i c h ist und sich dies nicht nut auf die t e x t u e l l e S u b s t i t u t i o n beschr~nkt. Dabei k a n n im a l l g e m e i n e n a n g e n o m m e n werden,

dab der P r o g r a m ~ i e r e r

den P r o g r a m m a u f b a u und die D a t e n s t r u k t u r e n u m f a n g r e i c h e r e r P r o g r a m m e vor dem D i a l o g festlegt, folgt p r o b l e m o r i e n t i e r t

d.h.

dieser Teil der P r o g r a m m d e f i n i t i o n er-

und im w e s e n t l i c h e n

u n a b h ~ n g i g von P r o g r a m m i e r -

sprache und -mittei. Die i n t e r a k t i v e A u s f ~ h r u n g von P r o g r a m m e n w e i s t dem P r o g r a m m i e r e r eine aktive Rolle zu. T y p i s c h e A k t i o n e n sind

a. das U n t e r b r e c h e n der A u s f ~ h r u n g aus dem P r o g r a m m heraus, e i n z u g e b e n oder eine F e h l e r s i t u a t i o n

um Daten

zu bereinigen.

b. das U n t e r b r e c h e n der A u s f O h r u n g von auBen,

um sie zu beenden,

an

e i n e r anderen P r o g r a m m s t e l l e oder zu einem s p i t e r e n Z e i t p u n k t fortzusetzen.

Die D e f i n i t i o n und I m p l e m e n t i e r u n g eines D i a ! o g s y s t e m s wie KANDIS fur eine b e s t i m m t e R e c h e n a n l a g e voraus,

setzt die E x i s t e n z eines B e t r i e b s s y s t e m s

das u n t e r a n d e r e m die p e r m a n e n t e Haltung,

den z e i l e n w e i s e n

T r a n s p o r t und die M a n i p u l a t i o n yon Daten erm~glicht. beispielsweise Gespr~chssysteme

Hierzu geh6ren

("time-sharing"-Systeme) . Die K o m m a n d o -

s p r a c h e n s o l c h e r Systeme b i e t e n dem B e n u t z e r g e w i s s e M 6 g i i c h k e i t e n des Dialogs,

der dadurch g e k e n n z e i c h n e t ist, dab die K o m m a n d o f o l g e w ~ h r e n d

des G e s p r ~ c h s

in A b h ~ n g i g k e i t yon b i s h e r i g e n E r e i g n i s s e n d e f i n i e r t wird.

B e s t i m m t e T ~ t i g k e i t e n wie die V e r w a l t u n g von D a t e i e n sind auch fdr den B e n u t z e r eines D i a l o g s y s t e m s

interessant,

so dab eine E i n b e t t u n g der

b e t r e f f e n d e n Kormaandos in das D i a l o g s y s t e m w ~ n s c h e n w e r t ist.

3. A r b e i t s b e r e i c h e

A m A n f a n g der B e t r a c h t u n g e n steht der B e g r i f f des " A r b e i t s b e r e i ches",

dem eine z e n t r a l e B e d e u t u n g zukommt. Wie im F a l l des D i a l o g s y -

stems A P L / 3 6 0

ist ein A r b e i t s b e r e i c h

(engl. : workspace)

t i o n s b e r e i c h z w i s c h e n P r o g r a ~ m i e r e r und D i a l o g s y s t e m .

der K o m m u n i k a -

Er b i l d e t stan-

d a r d m ~ B i g eine P r o g r a m m i e r u m g e b u n g fur alle A k t i o n e n des P r o g r a m m i e r e r s .

58

Ein A r b e i t s b e r e i c h w i r d e n t w e d e r durch das K o m m a n d o create



neu g e s c h a f f e n und s t a n d a r d m i B i g render

i n i t i a l i s i e r t oder ein schon existie-

(passiver) A r b e i t s b e r e i c h w i r d dutch

aktiviert.

Der alte Zustand dieses A r b e i t s b e r e i c h e s w i r d w i e d e r herge-

stellt. Die in einem A r b e i t s b e r e i c h v e r f [ g b a r e n Kommandos

lassen sich zu

drei G r u p p e n zusammenfassen:

i. S y s t e m k o ~ m a n d o s

dienen zur H e r s t e l l u n g und LSsung von V e r b i n d u n g e n

zur R e c h e n a n l a g e und zu der Benutzerstation. 2. B e r e i c h s k o m m a n d o s Definition,

dienen zur M a n i p u l a t i o n von P r o g r a m m e n sowie zur

E r w e i t e r u n g und V e r ~ n d e r u n g

des A r b e i t s b e r e i c h s

als Pro-

g r a m m i e r u m g e b u n g dieser Progran%me. 3. Sprachkontmandos sind A n w e i s u n g e n und V e r e i n b a r u n g e n der D i a l o g s p r a che. Dieser Begriff w i r d jedoch nur im Fall des D i r e k t m o d u s verwendet.

Bereichskommandos

e r m ~ g l i c h e n unter anderem folgende T~tigkeiten:

i. D e f i n i t i o n und A u s f ~ h r u n g von Segmenten, Kommandos

dienen,

die zur S p e i c h e r u n g von

und von M o d u l n als in sich a b g e s c h l o s s e n e n Pro-

g r a m m e i n h e i t e n der Dialogsprache. 2. Hinzuf~gen,

L~schen und U m b e n e n n e n yon Objekten,

A r t e n und Operatio-

nen in der S t a n d a r d p r o g r a m m i e r u m g e b u n g . 3. ~ b e r n a h m e von E l e m e n t e n p a s s i v e r A r b e i t s b e r e i c h e . 4. S i c h e r s t e l l e n des Zustands eines A r b e i t s b e r e i c h s

durch die S c h a f f u n g

einer Kopie.

4. S e g m e n t e und S e g m e n t e l e m e n t 9 Die i n t e r a k t i v e E n t w i c k l u n g und A u s f ~ h r u n g von P r o g r a m m e n

ist nur dann

m~glich, w e n n P r o g r a m m e oder P r o g r a m m t e i l e g e s p e i c h e r t w e r d e n kSnnen. N e b e n dem D i r e k t m o d u s w i r d ein "Speichermodus" Eingabezeichen

in ein "Segment"

se~m t i.I proc fac =

ben6tigt,

e i n g e t r a g e n werden:

(int n) in__~t:

1.2 if n=l then 1 else n*fac(n-l)

f i;

in dem alle

59

2.1 w r i t e ( " T a b e l l e

der Fakultiten");

2.5 for i to n do w r i t e


done;

e_ndse@m

Im a l l g e m e i n e n Fall b e s t e h t e~n Segment aus einer linearen Folge von "Segmentelementen"

(Inkrementen)

. Dabei ist mit e i n e m S e g m e n t e l e m e n t

eine V e r e i n b a r u n g oder A n w e i s u n g der D i a l o g s p r a c h e gemeint,

die selbst

in k e i n e r A n w e i s u n g oder V e r e i n b a r u n g e n t h a l t e n ist. Die "Adresse eines S e g m e n t e l e m e n t s " bezeichnung

und der

(ersten)

ergibt sich aus der Segment-

Z e i l e n n u ~ m e r des Elements.

Demnach besteht

das obige Segment t aus den E l e m e n t e n t[l.l]r

t[2.1],

t[2.5]

Auf dieser t e x t u e l l e n Ebene k~nnen --die S e g m e n t z e i l e n neu n u m e r i e r t werden. --Segmentelemente

g e l ~ s c h t und h i n z u g e f ~ g t werden.

--Segmentelemente

t e x t u e l l m a n i p u l i e r t werden~

Der Eingabe oder t e x t u e l l e n ~ n d e r u h g des Segments

folgt g e w ~ h n l i c h die

A u s f ~ h r u n g aller oder e i n z e l n e r E l e m e n t e des Segments. Ein S e g m e n t e l e m e n t heiBt

~'syntaktisch korrekt",

wenn

i. das E l e m e n t - s y n t a k t i s c h g e s e h e n - eine V e r e i n b a r u n g oder Anweisung der D i a l o g s p r a c h e

isto

2. yon jeder in dem E l e m e n t a u f t r e t e n d e n B e n e n n u n g feststeht, was sie benennt:

ein Objekt,

einen O p e r a t o r oder eine Art.

T r i t t ein s y n t a k t i s c h e r F e h l e r auf oder fehlt die in Information, w i r d der A n a l y s e v o r g a n g

(2) v e r l a n g t e

u n t e r b r o c h e n und der P r o g r a m m i e r e r

kann i n t e r a k t i v die n o t w e n d i g e n A n g a b e n und K o r r e k t u r e n eingeben.

Der S y n t a x a n a l y s e

folgt die A u s f ~ h r u n g des S e g m e n t e l e m e n t s

h~ngig yon anderen E l e m e n t e n Benennungen",

["inkrementelle Ausf~hrung")

unab-

~ Da "freie

f~r die es im S e g m e n t e l e m e n t keine V e r e i n b a r u n g gibt,

erst zum Z e i t p u n k t der A u s f ~ h r u n g des Elements

gebunden werden,

kann

die A u s f ~ h r u n g nut i n t e r p r e t a t i v erfolgen. Die E l e m e n t e eines Segments k~nnen zusammen, !iebiger R e i h e n f o l g e

a u s g e f [ h r t werden: exec t exec t[l.l]

einzeln oder in be-

60

exec t[2.1],

t[l.l], t[2.3]

Zu jedem S e g m e n t geh~rt eine P r o g r a m m i e r u m g e b u n g , nannt,

"Segmentumgebung"

ge-

in der die E l e m e n t e des Segments a u s g e f ~ h r t w e r d e n und in der

freie B e n e n n u n g e n g e b u n d e n werden.

Diese U m g e b u n g enth[it unter anderem:

a. die S t a n d a r d p r o g r a m m i e r u m g e b u n g

des A r b e i t s b e r e i c h s ,

d.h.

alle zu

e i n e m b e s t i m m t e n Z e i t p u n k t s t a n d a r d m ~ B i g b e k a n n t e n Objekte, Operationen und Arten. b. einen lokalen S p e i c h e r zur A u f n a h m e der dutch die S e g m e n t e l e m e n t e d e f i n i e r t e n Objekte. c. einen K e l l e r zur A u s f ~ h r u n g yon Operationen.

Segment

I 'text'

I 'code'

I

I

Zeile i

Zeile i

1

I

,dekZ

~

i 'envir'

I

tionstabelle Codespeicher

I

Zustandstabel!e

DekZara-

Textspeicher

I 'state'

Segmentumgebung

Die Z u s t a n d s t a b e l l e gibt Auskunft,

eb

--ein S e g m e n t e l e m e n t textuell g e ~ n d e r t ist. --ein S e g m e n t e l e m e n t s y n t a k t i s c h oder s e m a n t i s c h korrekt ist. --ob s y n t a k t i s c h e oder s e m a n t i s c h e Fehler eines S e g m e n t e l e m e n t s

abge-

fragt sind. --ob die Syntaxanalyse,

U b e r s e t z u n g eder A u s f ~ h r u n g eines Segmentele-

ments u n t e r b r o c h e n ist und w e l c h e Ursache vorliegt.

61

Das "Zusammensetzen"

yon S e g m e n t e n aus v o r h a n d e n e n S e g m e n t e n kann

auf z w e i e r l e i W e i s e geschehen:

a. durch t e x t u e l l e Substitution. Hat ein S e g m e n t e l e m e n t die F o r m copy < S e g m e n t e l e m e n t e >

,

so w i r d dieses E l e m e n t dutch die a n g e g e b e n e n S e g m e n t e l e m e n t e ersetzt, m~glicherweise

auch durch das g e s a m t e Segment.

regelt den A u s t a u s c h yon B e n e n n u n g e n aufrufs)

Eine E r s e t z u n g s l i s t e

( P a r a m e t r i s i e r u n g des Kopier-

: copy < S e g m e n t e l e m e n t e > w i t h =

b. durch Aufruf: Hat ein S e g m e n t e l e m e n t die F o r m exec < S e g m e n t e l e m e n t e > so w e r d e n diese Elemente,

,

m ~ g l i c h e r w e i s e das gesamte Segment,

d i e s e r S t e l l e in der S e g m e n t u m g e b u n g des a u f r u f e n d e n Segments

an ausge-

fHhrt.

5. M o d u l n

Im G e g e n s a t z

zu den im v o r h e r i g e n A b s c h n i t t b e s c h r i e b e n e n Segmen-

ten und S e g m e n t e l e m e n t e n sind "Moduln"

umfangreichere Programmst~cke

mit e i n e m w e s e n t l i c h s t ~ r k e r e n Z u s a m m e n h a l t der e i n z e l n e n Teile und e i n e r g r ~ B e r e n A b g e s c h l o s s e n h e i t nach auSen hin.

Sie ergeben sich oft

aus der Z u s a m m e n s e t z u n g m e h r e r e r S e g m e n t e u n d / o d e r Moduln, n a n d e r u n a b h ~ n g i g e n t w i c k e l t wurden, sen, und nun eine neue, des M o d u l b e g r i f f s Dennis

um b e s t i m m t e T e i l p r o b l e m e

gr~Bere P r o g r a m m e i n h e i t bilden.

S y n t a k t i s c h g e s e h e n hat ein M o d u l den f o l g e n d e n Aufbau:

< M o d u l b e n e n n u n g > ( < f o r m a l e Parameter>):

;

< V e r e i n b a r u n g n>; < A n w e i s u n g i> ;

< A n w e i s u n g m> endmodul

zu l~-

Die D e f i n i t i o n

folgt im w e s e n t l i c h e n den V o r s t e l l u n g e n von J.B.

[43 ~ber " p r o g r a m modules".

modul

die vonei-

62

Dabei k~nnen alle Vereinbarungen, alle Anweisungen oder alle formalen Parameter fehlen. Jeder Modul erh~it Daten ~ber Eingabeparameter, transformiert sie in einer bestimmten Weise und sendet Daten ~ber Ausgabeparameter anderen Moduln zu. Eingabe- und Ausgabeparameter sind formale Parameter eines Moduls. Wegen dieser Festlegung gibt eine nicht-lokale Benennung eines Moduls, die keine Standardbenennung ist, eine Art, ein Element einer Art oder einen Operator an. Die Bindung solcher Benennungen erfolgt dutch den Modulaufruf call <Modulbenennung>() Ein solcher Aufruf bewirkt folgendes:

i. Die Programmier~dmgebung wird festgestellt. 2. Ist der Modul noch nicht ~bersetzt, wird dies abh~ngig yon der speziellen Programmierumgebung nachgeholt, wobei der umgebungsabh~ngige Code parametrisiert wird, um ihn auch auBerhalb dieser Umgebung verwenden zu k~nnen~ andernfalls erfolgt die Bindung nichtlokaler Benennungen des Moduls in der speziellen P r o g r ~ m i e r u m g e bung. 3. Der Modul wird ausgefdhrt.

Da die Ausf~hrung eines Moduls interaktiv unterbrochen werden kann, ist es m~glich, da~ gleichzeitig mehrere Inkarnationen eines Moduls existieren, die sich dutch die Art der Bindung nicht-lokaler Benennungen unterscheiden~ Neben dem obigen Modulaufruf call .... , der - syntaktisch geseheneine Anweisung ist, kann an der Stelle einer Vereinbarung der Modulaufruf envir <Modulbenennung>() stehen, der die gleiche Wirkung hat. Zus~tzlich wird die Programmierumgebung dieses Modulaufrufs um die globalen Komponenten des aufgerufenen Moduls erweitert, sofern keine Kollision von Benennungen auftritt. G!obale Komponenten sind durch Vereinbarungen des Moduls eingef~hrte Objekte,

f~r die der Modul eine globale Spezifikation enthilt: 91obal a,b~def

Ein solcher Aufruf kann nur an bestimmten, syntaktisch festgelegten Stellen erfolgen, beispielsweise:

63

m o d u l ml(.o.):

;

level al begin envir m2(...); envir m3(...);

;

;

end; level a2 b e g i n

... end;

;

endmodul Diese V e r w e n d u n g yon M o d u l n u n t e r s t O t z t den m o d u l a r e n und hierarc h i s c h e n A u f b a u yon P r o g r a m m e n wie er bsp. ~ h n l i c h e r Ansatz

in [5] b e s c h r i e b e n

findet sich auch in der Sprache SIMULA

ist. Ein

[6].

Das folgende B e i s p i e l zeigt den groben A u f b a u eines P r o g r a m m i e r systems

fNr eine L I S P - ~ h n l i c h e

modul s p e i c h e r v e r w a l t u n g ( i n t

Sprache:

n):

mode link = s t r u c t ( r e f el cdr); m o d e el

= link s t r u c t ( r e f link car);

mode atomt= link s t r u c t ( t e x t t); new

If:n] e_~l freispeicher;

pro c dealloc = proc a l l o c = global o

o

,

,

,

,

,

(e_~im):

link, el, atomt, ,

,

> > F r e i g a b e eines S p e i c h e r p l a t z e s < <

el: > > B e l e g e n eines Speicherplatzes<<; dealloc,

alloc;

,

endmodul; m o d u l system: new el k e l l e r proc push =

:= nil;

(el m):

>>Keller erh~hen<<

;

pop = link: > > K e l l e r e r n i e d r i g e n < < proc cons =

(link lk, e_~l list) el:

proc atom =

(.link ik) bool

globa ! push, pop,

endmodul;

cons,

.....

; ;

: ... ;

atom, head,

tail, null;

;

64

modul o

.

I

.

,

syntaxanalyse: °

.

°

a

1

global o

°

~

.

.

°

.

.

sanw, .

saus,

sbed,

....

ibed,

...

;

.

endmodul; modul

interpreter:

global

ianw,

iaus,

;

endmodui Mit Hilfe modul

dieser M o d u l n

l~t

sich f o l g e n d e r

Modul

aufbauen:

ps:

level a b e g i n envir

speicherverwaltung(lO00);

level b b e g i n envir

system;

level

c begin envir

syntaxanalyse;

envir

interpreter;

end; end; end;

endmodul

.

Die textuelle

Anderung

tion der S e g m e n t u m g e b u n g pretation

erst w ~ h r e n d

Ausf~hrung eine ungen

eines M o d u l s

geeignete

dagegen

zur U b e r s e t z u n g s z e i t

ten Code aus. wird

spielsweise

setzt

voraus.

Die

Um eine e r n e u t e

aus.

die U b e r s e t z u n g

des M o d u l s

Bindung

Ubersetzung

sich daher

des g e s a m t e n

auswirkt.

Die in

von Benenn-

textuelle ~nderung wirkt

yon der Art der T ~ t i g k e i t

wenn w~hrend

Inter-

eines E l e m e n t e s

in dem sich die A n d e r u n g

auch dann,

und die M a n i p u l a -

der i n k r e m e n t e l l e n

und die s t a t i s c h e

der M o d u l u m g e b u n g

in A b h ~ n g i g k e i t

K o n t e x t bestimmt,

Segmentelementes

sich w e g e n

der A u s f ~ h r u n g

Zwischensprache

u n d die M a n i p u l a t i o n

meiden,

eines

wirkt

eines Modu!s

auf den erzeugModuls

zu ver-

ein m i n i m a l e r

Dies gilt bei-

der M o d u l a u s f ~ h r u n g

ein seman-

65

tischer F e h l e r a u f t r i t t und yon dem P r o g r a m m i e r e r i n t e r a k t i v b e h o b e n wird.

6. Eini~e E i ~ e n s c h a f t e n der D i a l o g s ~ r a q h e KANDIS Zwei K l a s s e n yon F o r d e r u n g e n b e e i n f l u s s e n die D e f i n i t i o n der Dialogsprache.

Die F o r d e r u n g e n der e r s t e n K l a s s e stehen im Z u s a m m e n h a n g mit

S t a p e l v e r a r b e i t u n g s s p r a c h e n wie A L G O L 68, SIMULA und PASCAL und betreffen P r o g r a m m i e r s t i l ,

L e s b a r k e i t und D o k u m e n t a t i o n yon Programmen,

K o n t r o l l s t r u k t u r e n und D a t e n s t r u k t u r e n .

Die F o r d e r u n g e n der zweiten

Klasse b e z i e h e n sich auf die F o r m u l i e r u n g i n t e r a k t i v e r T ~ t i g k e i t e n und b e t r e f f e n D e f i n i t i o n und A u s f ~ h r u n g von Programmen,

K o r r e k t u r syntak-

t i s c h e r und s e m a n t i s c h e r Fehler, die M ~ g l i c h k e i t der ~ b e r w a c h u n g der Definitions-

und A u s f ~ h r u n g s p h a s e

sowie die M a n i p u l a t i o n yon Daten

und P r o g r a ~ m i e r u m g e b u n g e n . Die w i c h t i g s t e n K o n t r o l l s t r u k t u r e n Laufanweisungen,

bedingte Anweisungen,

brechungsanweisungen, nur lokal gestattet.

sind W i e d e r h o l u n g s a n w e i s u n g e n , Fallunterscheidungen,

Sprunganweisungen,

Unter-

usw. S p r u n g a n w e i s u n g e n

sind

P r o z e d u r e n und K o r o u t i n e n sind w e i t e r e Mittel

zur S t r u k t u r i e r u n g eines Programms. Wie in A L G O L 68 und P A S C A L ist es m6glich, zugeh~rige Operationen ist aufgehoben.

zu definieren.

neue D a t e n t y p e n und

Der V o r r a n g zwischen O p e r a t o r e n

V e r b u n d a r t e n w e r d e n ~hnlich wie K l a s s e n in S I M U L A

d e f i n i e r t und das union - Konzept von A L G O L 68 ist auf diese A r t e n eingeschr[nkt.

7. Einige I m p l e m e n t i e r u n g s e i g e n s c h a f t e n Das D i a l o g s y s t e m setzt sich aus e i n e r A n z a h l von "Systemmoduln" zur D u r c h f ~ h r u n g der v e r s c h i e d e n e n A u f g a b e n des Dialogs

zusammen.

Systernmoduln sind in der Sprache E x t e n d e d /
auf der R e c h e n a n l a g e Burroughs

ist, und sind als K o r o u t i n e n organisiert. unter a n d e r e m --

ein L e s e p r o g r a m m

--

ein S y n t a x a n a l y s a t o r

--

ein u b e r s e t z e r

--

ein I n t e r p r e t e r

--

ein T e x t m a n i p u l a t i o n s p r o g r a m m

--

ein D a t e i v e r w a l t u n g s p r o g r a m m

Diese

die als

B6700 v o r h a n d e n

Solche S y s t e m m o d u l n

sind

66

Die T r a n s f o r m a t i o n des Textes einer S e g m e n t z e i l e oder einer Modul-zeile durch das L e s e p r o g r a F ~ b e s t e h t in der E r k e n n u n g von G r u n d s y m b o l e n wie Benennungen, W o r t s y m b o l e n ,

Zahlen,

Z e i c h e n r e i h e n oder Kommentaren.

Das S y n t a x a n a l y s e p r o g r a m m arbeitet nach einer

'top-down' M e t h o d e und

hat im Fall eines S e g e m e n t e l e m e n t e s bzw~ eines Moduls das Z i e l a x i o m bzw.

<Modul>.

FUr die E l e m e n t e eines Segments erzeugt der ~ b e r s e t z e r ein Codest~ck in einer Z w i s c h e n s p r a c h e ohne B e r ~ c k s i c h t i g u n g des K o n t e x t e s dieser Elemente.

Die C o d e s t ~ c k e w e r d e n von dem I n t e r p r e t e r verarbeitet,

der zudem die d y n a m i s c h e Bindung in der S e g m e n t u m g e b u n g v o r n e h m e n mu~. FUr einen Modul kann der ~ b e r s e t z e r w e s e n t l i c h e f f i z i e n t e r e n Code erzeugen,

da ihm w e g e n der A b g e s c h l o s s e n h e i t des H o d u l s m e h r Informa-

tion zur V e r f ~ g u n g steht. W ~ h r e n d der Interpreter im Fall eines Segm e n t e l e m e n t e s mit einer b i n i r e n O p e r a t i o n zuerst die Art der O p e r a n d e n b e s t i m m e n mu~, mit deren H e n n t n i s der O p e r a t o r i d e n t i f i z i e r t wird,

sind

bei einem Modul Art der O p e r a n d e n und der Operator m e i s t e n s bekannt. Es ist an dieser Stelle nicht sinnvoll,

auf den A u f b a u und die

F u n k t i o n der e i n z e l n e n Systen~noduln n~her einzugehen. immer w i e d e r die N o t w e n d i g k e i t ,

Es zeigt sich

einzelne M o d u l n neu zu definieren,

eine gr~Sere Effizienz des G e s a m t s y s t e m s

zu erhalten.

Die M o d u l a r i t ~ t

des Systems und die H i e r a r c h i s i e r u n g der S y s t e m m o d u l n im Sinne yon [4] und

[5] e r l e i c h t e r t diese A~fgabe.

um

67

Literaturverzeicnnis [1]

H. Rohlfing: "DIALIS - Ein ei~faches Dialogsystem fur eine Listensprache '~, 2. GI-Jahrestagung 1972, Lecture Notes in Economics and Mathematical Systems~ BD 78, Springer Verlag

[2]

E.W. Dijkstra: "Notes on Structured Programming" in O.J.Dahl et a! "Structured Programming", Academic Press, Bd 8, 1972

[3]

N. Wirth: "Program Development by Stepwise Refinement", CACM 14,4, pp 221-227

[4]

J.D. Dennis: "Modularity ~' in "Advanced Course on Software Engineering ~', Lecture Notes in Economics and Mathematical Systems, Bd 81, Springer Verlag, pp 128-182

[5]

G. Goos: "Hierarchies", wie i~

[4], pp 29-46

[6]

O.J. Dahl et a l : "SlMULA 67 CoMmon Base Language", Norwegian Computing Center, Forskningsveien lb, Oslo 3

Dipl.-Matho Helmut Roh]fing Fakult~t fur Informatik der Universit~t Karlsruhe 7500 Karlsruhe Postfach 6380

A PROJECT ORIENTED SUPPORT LIBRARY

R,W, FRIDAY

ABSTRACT

Ample evidence supports structured programming and implementation.

system integration

[SP] results in extraordinary

But as has been pointed

needed ~or development

the fact that the use o# successes

in system design

out a most basic and critical tool

of a system based on SP is a program support

library;

at

time the system montage is assembled from the various

components. The latest versions current state of the system are maintained

of all components making up the in the program support

library. A

program librarian not only maintains the library but also develops, maintains

complete

records regarding

all parts of the system.

updates,

and

The worK connected

wlth such e library is complex because of the large number of components

erlsing

out of the top down method basic to SP. POSL {project o_riented s_upport ~ibrary) and documentation principles gathered

system which supports

of SP. With POSL information

automatically;

the development

is a new library

of systems designed on the

normally produced by the librarian is

clerical tasks and safeguard

well and can be specified for either individual

procedures

components

are automated

or entire software

levels. POSL is unique in that the library contains not only components

but the entire program tree as well. All components

according to their olace in the tree as well as by name,

are cataloged

as

69

As the project grows, that is, as more and more compooents are created by the top down method, the tree grows to accommodate them. A new node for the tree is created by inventing a name for it and then informing POSL. Components can then be attached to the node. The exact position of the new node in the tree is determined as soon as a component from another node refers to a component in the new node. Nodes can be attached to a tree temporarily, testing or simulation of new features,

thus allowing

or they can replace already existing nodes

so that levels of software can be interchanged.

In any case the program tree

always reflects the total system structure and content at any time.

INTROOUCTION

The exact definition of exactly what constitutes a structured program is still being debated] '2 Nevertheless the use of certain common programming practices making up the current definition of SP has resulted in great success in system design and implementation~ But the top down method of programming native to SP gives rise to a large number of components;

a program

librarian must be employed to organize and maintain them. The program librarian can be placed in a position which isolates the programmer from the computer,

as shown in figure I.

Figure I Position oF the program librarian

t...... progrommy

]

I

program librarian

t

l Standard procedures

k

7O

The programmer program librarian.

requests

a

test run or update from the

The program librarian performs the requested task and gives the

output back to the programmer

after having documented

having noted which other components

changes to libraries,

end

are affected,

In order to perform the requested task the program librarian makes use of certain standard procedures.

These can be understood

procedures 4 or other files of control cards; links between the program librarian

to be cataloged

these standard procedures

and the computer,

are the

and the program support

library, An alternative between the standard procedures directly after the programmer. standard procedures

position for the program librarian would be

and the machine,

as shown in figure 2~ and not

The programmer would have direct access to the

rather than having to direct the librarian what to do. Figure 2 Alternative

position

for the program

librarian

programmer ~"

IX

.....

Standard procedures

program

1,ib,rarian

i

.......

' Computer and

program support

This arrangement program rather than a machine.

library

implies that the program librarian

The following question

is a

can be raised:

is it possible to automate the work of the program librarian thus making the arrangement

shown in figure 2 possible? Careful consideration

implementation

of the steps involved in system

show there are certain common steps where

librarian can be employed.

an automatic program

These common ~processes are described below, and then

POSL is introduced as a realization

of the concept of an automatic

librarian.

71

VIRTUA~ MACHINES AND THE PROGRAM TREE

One of the central concepts in SP is that o~ the virtual machine. which,

By a machine

(either virtue1 or real) is meant any piece 09 equipment

given well defined input, manipulates

it to produce well eefined output.

A programmer faced with a problem to solve generally has s specific machine to work with. This machine manipulates data only very remotely related to the data which interests him. But yet he is able to solve his problem~ he invents other ideal

or virtual machines which will perform those tasks needed

to accomplish the central task. These new virtual machines do not exist end so others are invented which perform tasks for the last set. This process is repeated until a set of virtual machines is designed which makes use of the functions available on the actual machine available. When a system has been implemented in this way it is possible to draw a tree structure which represents the system. At the root o9 the tree is the original task to be performed.

The various branches represent the expansion

o9 the problem into tasks to be performed by other virtual machines.

Finally, the

actual machine is represented at the highest level in the tree, A portion of such e tree is shown in figure 3, Figure 3 A possible

I •

jr/•

:

~

srogram

tree

/~"-'m--2 =e

I

A

\

I "A" represents the virtual machine which solves the original problem and provides services or 9unctions a I end a 2. These functions can be accomplished in terms of functions

provided by the virtual machines

"8" and "C".

These two virtual machines in turn require the use of services from the virtual machines

"0" and "E", Additional virtual machines used by "0" and "E" ere not shown~

72

The various virtual machines need not a l l

be written in the same language. For

example, A might be a source program end B,C,D, end E might be macros. be a load module, with B,C,D, and E being sets of object modules modules), These various types of components

Or A might

CYelocatable

can ell be present during the

implementation of any system.

THE SYSTEM INTEGRATOR

It ls clear that e system integrator

[SI) is needed to

construct the resultant virtual machine from the input functions. That is, it is not sufficient for virtual machines to exist; they must be combined. more concrete examplej

To give a

it is not sufficient that e motor and a steering wheel

exist and that an auto need them~ in order for the auto to run a mechanic must put them together.

If a programming system is being implemented this is the

task of the system integrator. It is also clear that there must be various types of Sis, each SI accepting a di%ferent type of virtual machine as input. Typical Sis used in system implementation

are macro processorsjlinKage editors,

and compilers.

THE SYSTEM INTEGRATION PROGRAM

Granted that the SI is capable o% creating the output virtual machine from the ~nput functions,

it must still be informed how to perform

this task. Referring beck to the example of the motor and the steering wheel, the mechanic who assembles the car must Know that these items do not go into the back sect. Exact information as to how the input functions are combined to produce the output virtual machine is specified to the SI vla the System integration program (SIP], Although it will not be discussed here, each type of SI accepts only those SIPs written in its own specific system integration program language

{SIPLJ.

The recognition o% e SIP as such is generally not easy because it is never looked at as a program. Yet they ere common. Consider the case where the SI is a linkage editor which belongs to IBM OS. Then the SIP conslsts of I.

the set of O0 statements defining the object libraries

2.

any INCLUOE cards specifying additional object modules to be used

3.

any possible cards defining an overlay structure

4.

information specified via the PARM parameter

5.

ESD and RLO card contained in the input object modules. Consider another case in which the SI is a macro processor.

Then the SIP is the program containing the various macro calls.

73

The SI uses the SIP then to construct the output virtual machine. This output virtual machine may serve as an input virtual machine to another type of SI. Finally the SI produces

listings which summarize the

construction process.

POSL

POSL consists of I. a library 2. an access method 3. a documentation system 4, services and safeguards,

THE POSL LIBRARY

Virtual machines are cataloged in the POSL library. Each virtual machine is given a unique name which can be referred to in SIPs. Cataloging of a virtual machine is equivalent to creating an empty box like those shown in figure 3, but containing no functions. Cataloging of a virtual machine does net imply that it is being used by any other virtual machine, and it does net associate any functions with the virtual machine. After a virtual machine has been cataloged functions may be associated with it. Note that the association of a function with a virtual machine {a cataloging process]

does not imply that the function is being used by any other

virtual machine. POSL libraries machines.

look the same for ell types of virtual

It is a restriction however that any particular POSL library contain

only virtual machines of the same type

Ii.e., written in the same language].

Current libraries do not have structures

like that of POSL,

All members are cataloged together in a big pot, with clumsy naming conventions taking the place of a real subsystem cataloging facility. BUILDING THE PROGRAM TREE

Links between the various virtual machines present in the library are mede explicit

by

one of two methods. The first method is indirectly

as a side effect of the POSL access method. The second method is directly through the use of the POSL documentation system.

74

THE POSL ACCESS METHOD

The POSL access method is a central building block for the implementation of any SI. It provides access to any part of the library, and as a side effect produces a default level of automatic documentation. The POSL access method can also be used as a building block for utility programs which service the library. The most important function of the POSL access method is the ability to allow explicit references to any specific function of any virtual machine in the library. The SI can request access to any soecific virtual machine function by name° Input of statements then proceeds automatically. The POSL access method also provides output into any existing virtual machine. Other library systems provide the ability to concatenate libraries but there are still difficulties when there are naming collisions. Furthermore the POSL access method recognizes the standard set of system components as a special case, so that mixing of POSL libraries and other libraries is possible. Without this ability the supporting operating system could not fit into the program tree. When the SI creates an output function the first task it must perform is to specify the name of the output function and the virtual machine to which it belongs. This e~feotively defines the root node in the program tree, and automatically gathered documentation information is built into a tree structure anchored at that node. Note that since all input virtual machines are accessed by the SI via the POSL access method, it is in a perfect position to Knew which ones were needed by the output function~ As was stated above, the definition of the output function establishes the root of the tree. The first set of functions speci%ied in the SIP are those which belong on the second level. The links between levels are established as soon as e function on one level requires the services of another function. The default level c~ documentation or program tree obtained in this manner contains virtual machine names, function names, and pointers between levels. In addition to this information it is clear which version of a function was used in making the output function. It is important to point out that not only does the output function "Know" which functions it uses, but also each input function "Knows" which output virtual machines it is a component of .

75

THE POSL DOCUMENTATION SYSTEM

In certain cases it is not feasible to write a new SI. If one has a macro processor or linkage editor already available it can be difficult to rewrite it just to include the POSL access method,

In this case the POSL

documentation system can be used to build the program tree. In the case where the POSL documentiation

system is to be used

a special preprocessor must be written which scans the SIP before it goes to the SI. This preprocessor calls the documentation system directly; however in this case the preprocessor can extract additional information ~rom the SIP which can be stored in the program tree along with the usual information.

The preprocessor can

even use the POSL access method, but with its documentat!on facilitles turned off. Note that in the previous case, when the POSL access method is being used, a programmer need do nothing extra. When the POSL documentation system is used in a preprocessor the linkage between the user and a SI must be via some standard procedure

(i.e. cataloged procedures or job macros) which invoke the

preprocessor for him. POSL SERVICES AND SAFEGUAROS

The POSL services and safeguards are a set of facilities and utilities designed to complement the other POSL components.

Utility routines can

be used to exhibit any part of the program tree es well as any member of it. Updating facilities are integrated

with the POSL documentation system so that

if a function is changed in any way the program tree is altered to reflect that change. Virtual machines affected by changes can be quickly located by a special POSL service routine. A special feature of POSL is the ability to interchange software layers. Such a need is basic to the idea of SP where virtual machines are being constantly redefined and extended.

In POSL this process proceeds without

the need to rewrite any virtual machine or SIP. One simply informs the POSL library via e service routine, and the access routines and documentation system take the appropriate actions. POSL also provides a range of freedom in the choices of safeguards and services for each virtual machine or individual function.

For

example, one can prohibit any reference to a specific function or virtual machine until it has been tested and officially released.

That is, there is a RELEASE

VIRTUAL MACHINE type of facility available in POSL. Conversely, can be taken out of service.

a virtual machine

76

Even the documentation various virtual machines.

system can be turned on or off for

This is useful when one does not want to include

finished virtual machines in the program tree. POSL allows multiple versions of a specific function to be present in the library. The number of older versions to be retained is optional. If one chooses to always retain two copies then the newest version can be tested and developed while the older version is being used.

CURRENT USE OF POSL

At the present time POSL is being used in connection with a special purpose macro processor.

The POSL library contains macro sets, each

macro set being identified with a specific virtual machine. The SIP is a mixture of language statements which ere ignored and the special preprocessor statements. The resultant source program is compiled by a compiler (for example PL/1 or assembler).

The entlre system runs under IBM OS. The program tree becomes quite complex since there are

several levels of virtual machines,

all implemented in terms of macro definitions.

A special purpose text editor,

developed independently

of POSb was easily integrated into the POSL system by writing a special preprocessor which uses the POSL documentation system. The special preprocessor Is linked to the text editor by means of a cataloged procedure,

so that to the user

the preprocessor is invisible. It has been the experience of the author that the implementation of a preprocessor for various types of SIPs presents no great difficulties.

In cases where the SIPL is particularily difficult a post-processor

has been used which

processes the listing output from the SI and uses this as the

source of information to be given to the POSL documentation system,

SUMMARY

POSL is a versatile automatic documentation system which is independent of any language. As such it can be used as an automatic librarian for systems implementation using languages which are currently available. The result is that information usually produced in a variety o~ forms can be unlfled, Although there is no claim that POSL is the only, or best possible form of the project oriented system library it is hoped that it will provide a basis for further worK in this area.

77

REFERENCES

I . Schroeder, M.D.

"A Brie# Report on the SIGPLAN/SIGOPS Interface Meeting",

Operating Systems Review. 7,No.3, 4-9 [July 1973)

2.

Peterson, W.W,, Kasami, T., and ToKura, N. " On the Capabilities of While, Repeat, and Exit Statements", Comm. ACM 18, No.8, 503-512 {August 1973]

3.

Baker, F,T. "Chie# Programmer meam Management of Production Programming", IBM Systems Journal M, No.l, 56-73 [1972]

4.

IBM System/360 Operating System : Job Control Language Reference

Address of the author: Dr. Richard W, Friday, softwarelabor, 8 MOnchen 2, Mozartetr. 17

FEEDBACK-FREE MODULARIZATION OF COMPILERS W. M. MCKEEMAN F. L. DEREMER

i. Introduction In an earlier paper[l] we discussed the matching of modular programming techniques to the inherent structure of the compilation process. In this paper we discuss processing associated with tree representations of the source program, making explicit the coordination of the processing modules in the horizontal fragmentation of the synthesis module.

As in the earlier paper, the highly structured translation a!go-

rithms suggested are useful only if the language being translated is equally structured to permit the isolation of the processing of different classes of information. The organization presented here is essentially that of a translator writing system being implemented under the direction of DeRemer. As will be apparent to the reader, this paper is a progress report, not a final statement.

Among DeRemer's goals, one is particularly rele-

vant to this paper:

to isolate subprocesses in translation that can

be fully specified in simple forms such as via grammars or tables. The immediate result is to eliminate much use of general purpose programming languages in compiler construction.

The presumption is

that restricting the compiler writer to limited, but adequate languages will reduce his efforts and improve his product. 2. Processin$ Tree Representations The parse tree is a well defined representation for any text described by an unambiguous context-free grammar.

It contains all the inform-

ation originally present in the source text of the program.

In

addition, it contains explicit representation of all of the information that is inherent in the grammatical description.

The parse tree is the

first of a sequence of trees used here as intermodular data structures. Each module leaves a tree which is closer to the target text while, perhaps, discarding some information not needed to accomplish further translation steps.

?9

Each tree processing module,

except the first, has an input tree, and

each, except the last, has an output tree.

The input tree is regarded

as a static, read-only data structure to be examined via its leafward pointing links; the output tree is regarded as a write-only data structure under construction. The implementor is free to use techniques for modification-in-place only when equivalent to the above stated restrictions; that is, only when the result is a feedback-free flow of information. The reasons behind this restriction are: (i) The modules are easier to understand, specify, implement and test. (2) The restrictions, While perhaps increasing the work some, are not unreasonable demands to make. (3) Feed-back free processing allows (but does not demand)

sequential

processing, hence allows (but does not demand) a multi-pass organization convenient for compiler execution memory management. Trees can be partially described by simple grammars (Tables 2.1a and 2.1b). The first grammar describes the connectivity of the tree; the second grammar describes the tree as a data object. The grammar notation is that of reference

[i].

The symbols "name", "integer",

etc., are left undefined because their representation is of little importance on this level of specification. The symbol "terminal", on the other hand, will be specified in some detail in subsequent paragraphs. program = tree; tree = node; node = terminal

I name node+;

Tree Connectivity Table 2.1a . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

program = tree; tree = node+; node = terminal I name descendant_count descendant_count = integer; link = pointer into_tree; Tree Representation Table 2. ib

link+;

8O

Starting with the parse tree we suggest a sequence

of seven trees as

noted in Table 2.2. PT

parse tree

AST

abstract

syntax tree tree

ST

standard

ACT

attribute

ADT

attribute distributed

tree

SET

sequential

expression

tree

SCT

sequential

control

collected

Tree Representations

tree

tree

of the Source Program

Table 2.2 In a very rough sense, reshaping

the tree transforming

the tree, pruning information

information

in tabular terminal nodes.

tree structure represents

process consists

At each stage the remaining

work yet to be done.

In the end, of course,

the entire program becomes a purely tabular structure for a conventional 3.

An AST is a condensed, Because

code

PT ~ AST renamed version

is discarded,

we always

PT ~ AST as a part of the algorithm ing ever forming the PT. [2,3].

of the PT.

Most superfluous

leaving a more convenient

the PT is so voluminous,

duction grammar

(sequential

computer).

The Transformation

structure

of

from the tree, and recording

computational

object.

specify the transformation

that deduces

This is accomplished

the PT itself, avoid-

by the use of a trans-

The range of possibilities

for an AST is

therefore defined to be that set of trees that can be specified by transduction

grammars.

3.1a and 3.1b.

An example is given in Table 3.1 and Figures

81

E = E

'+' T

=>

~ADD' E

I E '-' T

=>

T 'SUB'

E/~'--T I T

=>

T = T

'*' P

T;

=>

'~' E

I P P = '(' E

')'

T

=>

P;

=>

E

IV

=>

'VAR / ' V

V = IxW

=>

'x ~

I 'Y'

=>

'Y'

I

~

~Z ~

WE I

A Transduct~ion

Grammar

Table

for Expressions

3.1

..................................................

/Y\ /

E

+

T

\

T /P

P /

/V

E

-

T

\

/T

x

x

/

P\

//P

V \

Y A Parse Tree

for x*x + (y-z) Figure

3.1a

.................................................

ADD

VAR VAR VAR VAR x An A b s t r a c t

x

y

z

Syntax Tree Figure

3. ib

for x*x + (y-z)

82

4.

The Transformation AST ~ ST

Programming languages sometimes allow more than one way to specify the same result.

For example, attributes in PL/I may or may not be fac-

tored; certain expressions may or may not be parenthesized,

etc.

Some

are more subtle, such as the assignment implied by parameter passing. The result is that there are classes of ASTs knownto the language designer to be equivalent.

The transformation AST ~ ST [4] is designed

to reduce members of the classes to single standard members, when it can be done by local renaming and reordering of tree nodes. The semantic equivalence of two constructs can be precisely stated (not the semantics, but the equivalence) the other.

by mapping one construct into

For example, in the language PALl5] we can write either E1 where x = E2

or let x = E2 in E1 where E1 and E2 are expressions.

We state the equivalence of the

constructs by the mapping in Figure 4.116]. where E1

let

~ x

xf~E2E 1 E2

A Local Tree Transformation Figure 4.1 Each transformation rule consists of two parts, an "input" template and an."output" template.

These two correspond to the left and right

parts, respectively, or a production of a type 0 grammar.

However,

in this case the intent is to reorder, expand, and/or contract a local portion of a tree, rather than a local portion of a string. To "apply" a transformation we first find a subtree that the input template matches.

This establishes a correspondence between the

"variables" in the input template and subtrees of the matched one. Then we restructure the part of the tree involved in the match, so that the output template will match it, maintaining the correspondence between variables and trees established by the i~put template match. In general, this will involve reordering, duplicating, and deleting the subtrees as dictated by the number and position of occurrences of each distinct variable in the input and output templates.

83

5.

The Transformation

The attributes writer's

ST ~ ACT

of variables

viewpoint,

are where you find them.

they are best found collected

ments clustered at the head of a variable attributes

may depend upon the context

even more subtle conditions.

More generally

in which variables

of the corresponding

tions of the program can proceed. in Table

state-

are used or

In any case they must be gathered and

tabulated before the translation the form defined

scope.

From the compiler

in declaration

Upon completion,

executable por-

the ACT may have

5.1.

program = ACT; ACT = scope; scope = symbol_table

scope* command*;

symbol table = (name attributes)*; attributes

= explicit_attributes I implicit_attributes;

Attribute-collected Table

Tree

5.1

Within a scope we first have the table of local symbols, arbitrary

sequence of nested

(scope-free) required

commands.

The transformation AST ~ ST may have been

to bring the tree into this form if a scope can be delimited

by begin-blocks

(as in Algol-60)

identified with procedure generally defined Some attributes attributes

are explicitly

are implicit.

major purposes. sary attributes

as opposed

declarations.

to being exclusively

Or the ACT can be more

to allow for the less structured

such as addresses

supplied by the programmer.

In particular,

Other

machine related attributes

An important presumption

is that there are no neces-

that cannot be derived prior to the processing code.

That is, properties

the relative location of certain instructions, effect the attributes of variables. The algorithm

use of scopes.

are to be deriv~ed by the compiler as one of its

executable machine

can be implemented,

over trees[7,8]

of the machine,

of such as

are not allowed

to

of course, as an ad hoc tree search-

ing algorithm along the lines commonly Some work has been done, however, functions

then an

scopes, and finally the executable

found in contemporary

on applying Knuth's

to this problem.

compilers.

concept of

It is a particularly

84

attractive direction since declarative information is defined to be evaluable prior to the "main"computation (i.e., execution of the program).

Knuth's functions can therefore be presumed to be evaluable

for declaration processing without any great amount of iteration, hence efficiently. The approach is to specify ST ~ ACT as a set of symbol-table-valued functions over the ST (as opposed to Knuth's functions over the PT) together with a standard ACT building process.

We suspect that a

reasonable restriction to put on declarative linguistic constructs is that they can be processed by Knuth's functions in one pass over the ST; i.e., going down the tree via function calls and then back up the tree via function returns. To apply the functions to the tree we must be able to describe the nodes.

Knuth used the names of the non-terminal symbols, numbering

only for a repeated use of a name.

When regular expressions are used

it is simpler to use a purely numeric scheme. left part of a rule; i, 2, . ~

Zero designates the

the items in the right part; -i, -2, ...

the same items numbered from right to left; (k~l), (k,2), items in each repeated term on the right, etc.

... the

For example, suppose

we have a declarative subtree of the form shown in Figure 5.1.

~~ 'B' 'BIT' i

DECLARE ~~ i

'I' 'FIXED' i

tem 'X' ~ ' ~ 3 0 0

A Declarative Subtree of a ST for DECLARE B BIT~ I FIXED~

.

.

.

X(300) FLOAT;

Figure 5.1 The objective is to compute two functions, A and S, giving the relative offset and number of bits for each item. Table 5.2 define A and S.

The grammar and functions in

Terminal nodes (name, type and dimension)

have intrinsic values provided by a primitive function val.

85

DECLARE = item +

A(I,I)

-->

= 0,

A(I,I+I)

= A(I,I) + S(I,!),

S(0) = A(I,-I) item = name type dim

_->

+ S(I,-I);

S(0) = T(2)*val(3) Cval(2) T(2)

Declarative

Functions

Table 6.

The Transformation

The implicit symbol

'FIXED'

: 16

\val(2)

'FLOAT'

: 32

over a ST

5.2

ACT ~ ADT

links by name between

the leaves of the ACT and its

tables must be replaced by explicit attachment

attributes programming

to the leaves languages

the destination

themselves.

are identical,

of the distributed

by the compiler writer. attributes

= 'BIT': 1

= ~val(2)

of the important

The scope rules of most popular from the viewpoint

of trees,

What does need to be specified

is which

are needed by the later modules.

If the distribution

is to be accomplished

leaf names with pointers

by simply replacing

into the symbol tables,

ST ~ ACT ~ ADT may as well be accomplished names are to be replaced with attributes, be kept separate.

A before-and-after

the

the transformations

as one step.

If the leaf

the transformations

need to

view of a variable node is given

in Figure 6.1.

VAR i 'I '

VAR °>

40

Attribute Distribution

'FIXED '

for a Variable

of Type FIXED and Address Offset 40. Figure 6.1 The symbol

thus

information need not be specified

table nodes are no longer needed and can be deleted.

86

7.

The Transformation ADT ~ SET

The ADT is an executable form; that is, if we had tree executing hardware.

But we do not, so we must reform the tree into equivalent se-

quential code.

We expect rather long sequences of sequential code to

be branch free.

In particular,

expressions (not including Algol-60

conditional expressions) have this property.

We can replace each sub-

tree representing an expression with its Polish form, say. go directly to single address code.

Or we can

Figure 7.1 shows an example of

such a transformation.

AS SIGN ADD f ~VAR ~ 40 'FIXED' VAR MUL

N VAR

=>

40 'FIXED

POLISH VAR VAR CONST MUL ADD

/ / VSR CONST \ 40 'FIXED ' 3

40 'FIXED' 40 'FIXED' 3

Expression Flattening Figure 7.1 Note that assignments are not included in the expression flattening, but this adds only one tier to the flattened expression trees.

The

reason assignments are left alone is two-fold: it avoids the ambiguity between variable addresses and values, and assignments need to be synchronized with some types of branching (parameters, returned values, index control for loops, etc.). 8.

The Transformation SET ~ SCT

Having flattened the trees for everything except control constructs, we must finally provide a sequential representation for branch commands.

There may be two kinds: implicit and labelled.

The implicit

branches (if-then-else, loops, case, etc.) merely require the replacement of tree links with branch links. Labels, on the other hand, must be found before the linking can be done.

While ST ~ ACT could have

collected this information, it is safely deferred to this stage.

Most

of the tree has been pruned, hence the search will not be over a very large data structure. For example, suppose we have been processing a procedure call CALL P(x+3, 4)

87

and have arrived at the SET in Figure 8.1.

x has offset 40 and the

two formal parameters (now appearing explicitly in the tree) have offsets 60 and 64. CALL ASSIGN ~AR/POLkISH

ASSIGN /~POLI SH

CONST ADD

'P '

CONST

SET for CALL P(x+3, 4) Figure 8.1 The only change needed is to replace 'P' with a pointer to the corresponding procedure definition. The tree has become a graph; all names have finally been pruned; we are ready to emit fully sequential code. i0.

Conclusion

The SCT is as far as we can go without introducing serious machine dependencies. The remaining steps in the process fall beyond the scope of this paper. We have proposed a fairly elaborate structuring of the translation process. We are trying to follow the prescription in our present translator writing system effort. We expect to simplify the task of compiler writing, but only for languages with structure amenable to the restrictions of the system. References [I] McKeeman, W. M., Compiler Structure, Proc. USA-Japan Computer Conference, (Oct. 1972) 448-455. [2] Louis, P.M. and Sterns, R. E., Syntax-directed Transduction, JACM v. 15, n. 3 (July 1968) 465-493. [3] DeRemer, F. L., Practical Translators for LR(k) Languages, PhD Thesis, MIT, Cambridge, Mass. (1969). [4] Wozencraft, J.M. and Evans, A., Notes on Programming Linguistics, Dept. E.E., MIT, Cambridge, Mass. (1971).

88

[5] Evans, A., PAL, A Language for Teaching Programming Linguistics, Proc. 23rd National Conf. of the ACM (1968) 395-403. [6] DeRemer, F.L., Transformational Grammars for Languages and Compilers TR50, Computing Laboratory, University of Newcastle-on-Tyne, England (submitted for publication). [7] Knuth, D.E., Semantics of Context-free Languages, Math Systems Theory J., v. 2, n. 2 (1968) 127-146. [8] Wilner, W. T., Declarative Semantic Definition, STAN-CS-233-71, PhD Thesis, Stanford, CA (1971).

Professor William Marshall McKeeman Information Sciences The University of California at Santa Cruz, California 95064 USA Professor Franklin L. DeRemer Information Sciences The University of California at Santa Cruz, California 95064 USA

ZUR MINIMALIT~T DES HILFSZELLENBEDARFS YON SYSTEMATISCH ~BERSETZTEN AUSDRUCKEN U. PETERS

I. K u r

z f as

sung

Wir betrachten Ausdr~cke

(im Sinn etwa von ALGOL), die aus runden Klam-

mern, un~ren und bin~ren Operatoren und Operanden bestehen,

ferner

deren systematische Ubersetzung in Folgen von DreiadreBbefehlen Kellerverfahren

(das

[I] z.B. induziert stets systematische Ubersetzungen)

und wollen den maximalen Hilfszellenbedarf yon ~bersetzten Ausdr~cken (das ist unsere Kostenfunktion)

minimieren.

Nimmt man als 0peranden

unserer Ausdr~cke einfache gew~hnlicheVariable fHr jedes Zwischenergebnis

genau 1 H i l f s z e l l e

und unterstellt man,daB ben6tigt wird, so ist

das in [2] angegebene systematische Verfahren OV optimal;

dies liegt im

wesentlichen daran, daS dann unter allen optimalen ~bersetzungen eines Ausdrucks

immer auch systematische Ubersetzungen existieren.

L~Bt man

dagegen als Operanden auch ~beriange Variable, Vektoren und derg!eichen zu und unterstellt man dementsprechend, eine positive, ben~tigt wird

zur ~bersetzungszeit

dab fur jedes Zwischenergebnis

ermittelbare Anzahl yon Hilfszellen

(diese Anzahlen bilden die sog. Best~ckung),

so ist das

Verfahren OV i.a. nicht mehr optimal, da sich nun unter allen optima!en Ubersetzungen nicht in jedem Fall systematische finden. Durch zus~tzliche Forderungen an den Ausdruck oder an die Best~ckung kann OV jedoch die Optimalit~t der Ubersetzung garantieren.

Dieses Ziel durch

eine mehr oder weniger weitgehende Verallgemeinerung der systematischen ~bersetzungen erreichen zu wollen erscheint uns dagegen aussichtslos. 2. E i n l

eitunq

Die hier betrachteten Ausdr~cke runden Klammern,

(im Sinn etwa von ALGOL)

bestehen aus

un~ren und bin~ren Operatoren und Operanden.

randen nehmen wir zun~chst gew~hnliche einfache Variable,

Als 0pe-

sp~ter dann

gew~hnliche Vektoren. Der Einfachheit halber wollen wir keine Beziehungen zwischen den Operanden zulassen: Wir setzen sie als paarweise voneinander verschieden benannt voraus.

Einen jeden solchen Ausdruck

9O

~bersetzen wir in eine Folge von DreiadreSbefehlen,

fur we!che gilt:

Wertet man den urspr~nglichen Ausdruck und die Folge von DreiadreSbefehlen

(den ~berset~ten Ausdruok)

im Sinn der Computerverkn~pfungen

so sind die erhaltenen Resultate stets identisch,

aus,

sofern die Auswertung

ohne Fehlerabbruch m~glich ist. Unter dem Hilfszellenbedarf verstehen wir diejenige Menge an Speicherzellen,

die der ~bersetzte Ausdruck zur

Abspeicherung yon Zwischenergebnissen ben~tigt. Unsere Kostenfunktion ist die Maximalanzahl von relevant besetzten Hilfszellen des ~bersetzten Ausdrucks;

diese Kostenfunktion wollen wir dutch geelgnete ~ber-

setzungsverfahren minimierent wobei wir uns jedoch auf systematische ~bersetzungen von AusdrHcken beschr~nken. verfahren von SAMELSON und BAUER

So induziert z.B. das Keller-

[i] stets systematische Ubersetzungen,

nimmt aber leider keine R~ckslcht auf unsere Kostenfunktion.

Jedem der yon uns betrachteten AusdrOcke

l~Bt sich, von unn~tigen Klam-

merungen abgesehen, bijektiv ein markierter bin~rer Bau/n zuordnen;

die-

ser splegelt die Klammerung und die Priorit~ten der Operatoren wider und es gilt: Aus jedem Knoten entspringen entweder keine oder genau zwei nichtleere ~ste.Die Zuordnung Ausdruck --- Baum schlieSt w~re sie nicht bijektiv) (Bl~tter) gen

(sonst

eine Markierung des Baums ein: Die Spitzen

des Baums sind mit den entsprechenden Operanden und die sonsti-

(inneren)

Knoten mit den entsprechenden Operatoren markiert. Da wir

fast stets gleich yon dem betreffenden

(markierten)

Baum ausgehen, wet-

den wir nut selten von Ausdr~cken und Ubersetzungsm~glichkeiten,

son-

dern vor allem yon B~umen und Abbauweisen reden° Damit unsere B~ume auch im Fall von un~ren Operatoren bin~r sind, vereinbaren wir, den dann nur vorhandenen einen Operanden als Linksoperanden des un~ren Operators zu behandeln und als Rechtsoperanden elnen operanden PSO dazuzunehmen.

Beispiel

zeichen) : Aus ~(a/(~(b-c)))

wird

k~nstlichen Pseudo-

("~" bezeichne das un~re Minus-

(a/((b-c)%PSO))%p~so.

zur Bijektivit~t

der Zuordnunq Ausdruck 4-- Baum sei schlieSlich noch angemerkt, dab wir voraussetzen,

dab f~r den Fall der Zusammenfassung mehrerer Operatoren

der gleichen Priorit~t eine Eindeutigkeit erzeugende Konvention vorhanden ist. In unseren Beispielen schlieSen wir uns dabei an ALGOL 60 an; so ist etwa mit dem Ausdruck a+b+c+d der Ausdruck

((a+b)+c)+d gemeint.

91

3. P r

~ l i m i n a r i e n

Definition

i:

Ein bindrer Baum B ist eine endliche,

n i c h t l e e r e Menge yon Z e i c h e n r e i -

hen K, Knoten genannt,

aus

von K E B zu B geh6rt.

Wir v e r l a n g e n zusMtzlich, dab m i t K, KO c B

{0,I} W , so dab jede A n f a n g s z e i c h e n r e i h e K'

auch K1 ~ B und mit K, K 1 E

Anmerkung: erw~hnt,

B auch KO ¢ B ist.

Die von uns b e t r a c h t e t e n B~ume sind, w i e in der E i n l e i t u n g

z u s M t z l i c h marklert.

Bedeutung,

Die M a r k i e r u n g ist jedoch so se!ten von

da8 wir sie nur dann a u s d r ~ c k l i c h im Text e r w ~ h n e n bzw.

den B e i s p i e l e n h i n s c h r e i b e n ,

falls sie gerade w i c h t i g

Die totale O r d n u n g 0 < 1 der Menge

in

ist.

{0,I} i n d u z i e r t eine l e x i k o g r a p h i s c h e

O r d n u n g < • der K n o t e n eines Baums. FUr

" K' ist echte A n f a n g s z e i c h e n -

reihe von K " s c h r e i b e n wit K' < • K.

D e f i n i t i o n 2: K' ist Naohfolger von K, w e n n E' = KO o d e r K' = K1 ist. U m g e k e h r t d a n n K Vorg~nger von K'; ferner sind KO und K 1 N a c h b a r n

ist

voneinander.

Knoten, die b e z ~ g l i c h < • m a x i m a l sind, nennen wir Spitzen

(BlHtter),

die O b r i g e n K n o t e n n e n n e n wir innere Knoten, den b e z ~ g l i c h < • m i n i m a len

(leeren)

Bezeichnung:

K n o t e n e nennen wlr Wurzel des Baums B.

Mit dem E p s i l o n ~ b e z e i c h n e n wir sowohl die W u r z e l n u n s e r e r

B~ume als auch die m e n g e n t h e o r e t i s c h e E l e m e n t b e z i e h u n g ;

aus dem K o n t e x t

geht immer e i n d e u t i g hervor, was jeweils g e m e i n t ist.

D e f i n i t i o n 3: Eine Abbauweise M i s t (IK,< .) auf und

[l:x]

bijektive,

eine bijektive,

([l:IIKl],>), wobei

:= {i ¢ NI

1S

o r d n u n g s t r e u e A b b i l d u n g von

IK die M e n g e der inneren K n o t e n yon B

i ~ x} ist. Die Kellerabbauweise

M K ist die

in b e i d e n R i c h t u n g e n o r d n u n g s t r e u e A b b i l d u n g yon

(B,< .) auf

([1:IIKI],>).

A n s c h a u l i c h g e s p r o c h e n ist eine A b b a u w e i s e eine A u f z ~ h l u n g der inneren K n o t e n eines Baums, w o b e i l e t z t e r e m i t der O r d n u n g < • des Baums "vertr~glich"

sein muB. G e d a n k l i c h geh~rt zu einer A b b a u w e i s e

G e n e r i e r u n g der z u g e h ~ r i g e n D r e i a d r e B b e f e h l s f o l g e dazu.

auch noch die

92

Anmerkung:

U n t e r einem Ubersetzungsverfahren

stehen wir einen A l g o r i t h m u s ,

bzw. Abbauverfahren

ver-

der, a n g e w a n d t auf einen A u s d r u c k bzw.

m a r k i e r t e n Baum, eine U b e r s e t z u n g dieses A u s d r u c k s g e n e r i e r t bzw. einen A b b a u des m a r k i e r t e n Baums d u r c h f H h r t und damit ebenfa!is einen ~bersetzten A u s d r u c k generiert.

Anmerkung:

Die K e l l e r a b b a u w e i s e ist gerade die vom K e l l e r v e r f a h r e n

d u z i e r t e Abbauweise.

Dabei stellen wir B~ume a n s c h a u l i c h so dar, dab

die l-Zweige nach links und die O - Z w e i g e nach rechts gehen, B =

in-

{e,O,l,O0,Ol,lO,ll,lO0,101}

z.B.

f~r

:

D e f i n i t i o n 4: • ~ K }von

B n e n n e n wir Teilbaum yon B

Eine A b b a u w e i s e M heiBt systematisch,wenn

f~r jeden inneren Knoten K,

Die T e i l m e n g e T K := { K'

I K'

mit der Wurzel K. D e f i n i t i o n 5:

fur den auch K1 und KO innere Knoten sind, e n t w e d e r max

{M(K')}

<

K' ~ IK(TKI)

min

{M(K')}

K'

~ IK(TKO)

K'

c IK(TKo)

oder rain K'

{M(K') }

>

~ IK(TKI)

{M(K') }

max

gilt. A n s c h a u l i c h g e s p r o c h e n ist eine A b b a u w e i s e den T e i l b a u m T K

(K innerer Knoten)

systematisch, wenn fur je-

e n t w e d e r zuerst alle inneren Knoten

des linken Astes TKI von T K und dann alle inneren K n o t e n des rechten A s t e s TKO a u f g e z ~ h l t w e r d e n oder umgekehrt;

a b s c h l i e S e n d ist K selbst

93

aufzuz~hlen;

auf Grund der D e f i n i t i o n

3 einzelnen A u f z ~ h l u n g e n gez~hlt w e r d e n d~rfen. Satz

keine

gilt weiter,

sonstigen

Beispie!e

dab zwischen diesen

inneren Knoten des Baums auf-

f~r systematische

Abbauweisen

liefert

I:

Kellerabbauweisen

sind systematisch.

Beweis: Seien K,KI und KO innere Knoten von B. FHr alle Klx, KOy ~ B gilt: Klx .> KOy. Nach D e f i n i t i o n

foigt: MK(KIx)

max{MK(Klx) } < min{MK(KOy) }

q.e.d.

4. D e r

g ew@hn

1 i che

In diesem A b s c h n i t t fache g e w @ h n l i c h e

duziert,

und unterstellen,

ben~tigt wird.

unserer A u s d r ~ c k e

Wir geben ein A b b a u v e r f a h r e n

dab OV f~r jeden Baum eine systematische A b b a u w e i s e

die bez~glich

k(K)

ein-

daS f~r jedes Zwischener-

unserer K o s t e n f u n k t i o n

optimal

nieren wir zun~chst die sog. B a u m b e w e r t u n g s f u n k t i o n :=~O

(FI)

Damit:

1

nehmen wir als O p e r a n d e n

Variable

gebnis nur 1 Hilfszelle an und zeigen,

F al

< MK(KOy).

OV in-

ist. Dazu defi-

k I B ~ INo:

, falls K Spitze Yon B

[ min{maxKl,maxKo}

, sonst

mit maxKl

:= max{k(Kl) ,l+k(KO) }

maxKo

:= max{k(KO) ,l+k(Kl) } .

(F2)

Definition

des V e r f a h r e n s

OV:

Sei A der zu ~ b e r s e t z e n d e Ausdruck. i) Man erstelle den zu A gehSrigen m a r k i e r t e n

Baum B und bewerte

B ge-

m,S der Funktion k aus (FI), indem man jeden Knoten K ~ B mit k(K) ~ markiert. 2) Man baue B system sch ab unter B e r ~ c k s i c h t i g u n g der folgenden Vorschrift: tun;

Ist K Spitze yon B, so ist fur den A b b a u yon T K nichts

zu

ist K innerer Knoten von B, so treffe man gem~B dem A s t a u s w a h l -

Kriterium

(F3) die Entscheidung,

ob zuerst TKI und dann TKO abzu-

94

bauen ist oder umgekehrt.

Astauswahl-Krlterium:

(F3)

maxKl S maxKo ~

TKI zuerst abbauen

Def

(andernfalls TKO)

Satz 2: Sei A der zu Gbersetzende Ausdruck und B = T g der dazugeh6rige markierte Baum. Dann gilt: k(z) gibt den maximalen Hilfszeilenbedarf des gem~B OV Gbersetzten Ausdrucks A an. Beweis: Siehe [5] , Satz I0. FUr die Praxis handlicher werden die Funktion k und das Astauswahlkriterium dutch folgende Umformung: I (FI')

k(K) =

0 k(Kl) l+k(Kl) k(KO)

(F3')

k(Kl) ~ k(KO) ~

falls K Spitze von B falls k(Kl) > k(KO) falls k(Kl) -- k(KO) falls k(Kl) < k(KO) TKI zuerst abbauen

(andernfalls TKO).

In dieser Form findet sich OV in [2], [3] und [4].

Bezeichnungen: Sei A ein Ausdruck und M ein Abbauverfahren°

Dann sei MAdie von M in-

duzierte Abbauweise von A, MA(A) der gem,S M A ~bersetzte Ausdruck und MH(MA(A))

der Maximalbedarf

an Hilfszellen von MA(A). Dann gilt, wenn

E die Wurzel des zu A geh~rigen Baums ist, nach Satz 2: MH(OVA(A)) Damlt kann man zelgen Satz 3: Das Verfahren OV ist optimal, d.h. es gilt: (VA) (VMA) (MH(OV A(A)) S MH(M A(A))). Beweis: Siehe

[5] , Satz ii.

=k(~l

95

Satz 4: Im g e w G h n l i c h e n Fall gibt es u n t e r allen o p t i m a l e n A b b a u w e i s e n stets auch systematische.

Beweis: Dies folgt u n m i t t e l b a r aus der D e f i n i t i o n von OV und Satz 3.

5. D e r

vet

al

i g e m e i n e r

te

Fall

In d i e s e m A b s c h n i t t n e h m e n wir als O p e r a n d e n u n s e r e r A u s d r G c k e w i e d e r g e w ~ h n l i c h e Gr~Ben,

aber d i e s m a l nicht nur e i n f a c h e Variable,

auch G b e r l a n g e Variable,

Vektoren, M a t r i z e n und dergleichen.

sondern Dement-

s p r e c h e n d u n t e r s t e l l e n wir nun, dab fGr jedes Z w i s c h e n e r g e b n i s ~bersetzungszeit

ermittelbare,

eine zur

p o s i t i v e A n z a h l von H i l f z e l l e n b e n S t i g t

wird. Diese A n z a h l e n g e b e n wir uns in F o r m der sog. B e s t G c k u n g s f u n k t i o n h

J IK ~IN vor, w o b e i IK w i e d e r die M e n g e der inneren Knoten von B ist

und h(K)

den H i l f s z e l l e n b e d a r f des zum inneren Knoten K g e h S r i g e n Zwi-

schenergebnisses

angibt. Wit w e r d e n nun die B a u m b e w e r t u n g s f u n k t i o n k

und damit das V e r f a h r e n OV v e r a l l g e m e i n e r n und p r G f e n

, in w e l c h e m Aus-

maB OV w e i t e r h i n o p t i m a l ist.

V e r a l l g e m e i n e r u n g der F u n k t i o n k: 0

(F4)

k(K)

:=

, falls K Spitze von B

max{h(K), min{maxKl,maxKo}}

, sonst

mit maxKl

:= max{k(Kl) ,h{Kl)+k(KO) }

maxKo

:= m a x { k (KO) ,h (KO) +k (KI) }.

(F5)

Dabei w i r d v o r a u s g e s e t z t , h(K)

dab h auf ganz B f o r t g e s e t z t w u r d e v e r m 6 g e

:= 1 fGr alle Spitzen K yon B.

Die D e f i n i t i o n des V e r f a h r e ~ O V

mit seinem A s t a u s w a h l - K r i t e r i u m

(F3)

gilt unver~ndert. Satz 5: Sei A der zu G b e r s e t z e n d e A u s d r u c k und

(B,h)

=

(T ,h) der d a z u g e h ~ r i g e

96

best~ckte

(und markierte)

Baum. Dann gilt: k(¢) gibt den maximalen

Hilfszellenbedarf des gem~B OV ~bersetzten Ausdrucks A an. Beweis: Siehe [5] , Satz 18. Wieder l~Bt sich die Funktion k und das Astauswahl-Kriterium

(F3)

urn-

formen : O (F4 ')

k (K) = {

falls K Spitze von B

max{h(K) ,k(Kl)} f~r k(Kl)-k(KO)

> h(Kl)

max{h(K) ,k(KO) } f~r k(Kl)-k(KO)

< -h(KO)

max{h(K) ,h(Kl)+h(KO)+min{d(KO) ,d(Kl) }} , sonst wobei d(K)

:= k(K)-h(K) gesetzt wurde.

Man ~berzeugt sich leicht, dab sich daraus f~r h ~ 1 die Funktion k aus (FI') ergibt. Das Astauswahl-Kriterium

(F3) l~Bt sich wie folgt umfor-

men: (F6')

d(Kl) ~ d(KO) ~

TKI zuerst abbauen

(andernfalls TKO)-

Man ~berzeugt sich leicht, dab sich daraus f~r h ~ i das AstauswahlKriterium

(F3') ergibt.

(F6') wird in [5] als Formel

(F34) abgeleitet.

Bezeichnungen: Wir ~bernehmen die Bezeichnungen A, M, M A, MA(A) und MH(MA(A))

aus Ab-

schnitt 4. Ferner bezeichne MAS eine systematische Abbauweise M A v o n

A

und (B,h) den zu A geh~rigen best~ckten und markierten Baum. Nach Satz 5 gilt: MH(OVA(A))

= k(¢). Damit ist formulierbar

Satz 6: Das Verfahren OV ist relativ optimal, d.h. bez~glich aller systematischen Abbauweisen MAS von (B,h) gilt: (VA) (VMAs) (MH(OVA(A)) ~ MH(MAs(A))). Beweis: Siehe

[5] , Satz 20.

Leider ist OV nun aber nicht mehr absoiut, d.h. fur jeden best~ckten Baum (B,h), optimal, wie etwa der folgende Satz ergibt:

97

Satz 7: Zu jeder B a u m l ~ n g e m ~ 4 gibt es einen b e s t H c k t e n Baum

(B,h) , f~r w e l -

chen OV nicht optimal arbeitet.

Beweis:

Siehe

[5], Satz 24.

Wit b e s c h r ~ n k e n uns h i e r darauf, ein k o n k r e t e s B e i s p i e l anzugeben, w e l c h e s O V nicht optimal arbeitet. (B,h)

f~r

Sei

= { (~,4) , (1,25) , (0,20) , (11,3) , (10,2) , (01,12) , (00,ii) , (111,26) (110,5) , (I01,I) , (i00,I) , (011,i) , (010,i) , (O01,i) , (O00,I) , (Iiii,I) , ( i i i 0 , i )

Wie erinnerlich,

, (ii01,I)

, (iiO0,I)

h a b e n wit die B e s t ~ c k u n g h v e r m ~ g e h(Spitze)

ganz B fortgesetzt.

:= 1 auf

In u n s e r e m B e i s p i e l slnd die Spitzen die e i n z i g e n

Knoten mit der B e s t H c k u n g

i. Um V e r w i r r u n g e n zu vermeiden,

stellt, daS der t a t s ~ c h l i c ~ Z e l l e n b e d a r f der Ausdrucks

}.

so klarge-

( O r i g i n a l - ) O p e r a n d e n des

f~r alle B e t r a c h t u n g e n d i e s e r A r b e i t u n e r h e b l i c h ist, da wit

voraussetzen,

dab die O r i g i n a l o p e r a n d e n u n m i t t e l b a r in den e r z e u g t e n

D r e i a d r e S b e f e h l e n v e r k n ~ p f t w e r d e n k6nnen. Das angegebene B e i s p i e l b e s i t z t 896 m ~ g l i c h e A b b a u w e i s e n , w o v o n 16 system a t i s c h und 112 o p t i m a l sind; der m i n i m a l e M a x i m a l b e d a r f b e l ~ u f t sich auf 45 Hilfszellen.

Die folgende o p t i m a l e A b b a u w e i s e sei h e r a u s g e g r i f f e n :

Knoten

aktueller Hilfszellenbedarf

Ii0

5

Iii

31

ii

3

O0

14

Ol

26

O

23

I0

25

1

45 4

Mit

(F4) und

(F5) folgt welter:

keine s y s t e m a t i s c h e A b b a u w e i s e , auskommt.

k(~)

= 48; nach Satz 6 gibt es also

die mit dem M i n i m u m von 45 H i l f s z e l l e n

Mit d i e s e m B e i s p i e l und Satz 6 folgt

Satz 8: Es gibt b e s t H c k t e B~ume

(B,h), d e r e n s ~ m t l i c h e o p t i m a l e A b b a u w e i s e n un-

98

systematisch

sind.

In genau diesen F~llen arbeitet das V e r f a h r e n OV

nicht optimal.

Wegen der Bekanntheit

und E i n f a c h h e i t

aber doch darum bemGht, terhin optimal

des V e r f a h r e ~ OV haben wir uns

F~lle h e r a u s z u k r i s t a l l i s i e r e n ,

in denen OV wei-

ist:

Satz 9: Das V e r f a h r e n OV ist fur den Ausdruck A optimal, (VMA) (MH(OV A(A)) falls L~nge

d.h. es gilt

S M H ( M A(A))) ,

(B) ~ 3 oder falls fur jeden inneren Knoten K von B min-

destens eine der folgenden Bedingungen

gilt:

I) K1 oder KO ist Spitze von B 2) k(Kl)

- k(KO)

>_ h(Kl)

3) k(Kl)

-k(KO)

<-h(KO)

4) d(KI)

• d(KO)

= 0

5) h(Kl)

_< min

{ h(Klx)

i x c {0,i} W, Klx c IK } und

h(KO)

<_ min

{ h(KOx)

i x c {0,I} ~,

wobei

IK die Menge der inneren Knoten von B ist.

Beweis:

Siehe

[5]

, Satz

KOx c IK },

19 und Satz 21.

Da OV nicht absolut optimal

ist, ist klar, dab man die O p t i m a l i t ~ t

OV nur durch Zusatzforderungen f~lle von Satz 9 illustrieren

I) Zus~tzliche F o r d e r u n g e n

erzwingen kann.

von

Die folgenden Spezial-

solche Zusatzforderungen:

an den Baum B:

Korollar O: OV ist fur alle B~ume Korollar

(B,h) mit L~nge

(B) ~ 3 optimal.

i:

OV ist f~r alle b e s t ~ c k t e n Gerten optimal. Baum,

Dabei

ist eine Gerte ein

f~r den gilt: FUr jeden inneren Knoten K ist K1 oder KO eine

Spitze. Korollar

2:

OV ist fHr die folgenden g e r t e n ~ h n l i c h e n

B~ume

(B,h) optimal:

FOr jeden inneren Knoten K von B ist K1 oder KO eine Spitze oder doch eine Spitzenwurzel,

d.h.

KII und KIO bzw.

KOI und KOO sind Spitzen.

99

2) Z u s ~ t z l i c h e Korollar

Forderungen

in den K n o t e n

B~ume

Korollar

Hierunter

f~llt

optimal, Wege

f~r die h entlang

in B

aller

(nicht n o t w e n d i g

streng)

insbesondere

der g e w S h n l i c h e

Fall h ~ i.

4:

OV ist f~r d i e j e n i g e n in den K n o t e n monoton

B~m~e

(B,h)

optimal,

I und O b e g i n n e n d e n

Wege

fHr die h entlang

in f o l g e n d e r

Weise

aller

(i.a.streng)

f~llt:

h (K)

, falls

K1

, KO

h(Kl)

, falls

K1

~ IK und KO Spitze

h(KO)

, falls

KO ~ IK und K 1 S p i t z e

8 l~Bt sich

allgemeinerten scharf

(B,h)

1 und 0 b e g i n n e n d e n

steigt.

Anmerkung:

Satz

h:

3:

OV ist fur d i e j e n i g e n

monoton

an die B e s t ~ c k u n g

auch

Fall

so i n t e r p r e t i e r e n ,

die E i n s c h r ~ n k u n g

ist und der G e d a n k e

oder w e n i g e r

diesen Versuch

Abbauverfahren

dab

im jetzt b e t r a c h t e t e n

auf s y s t e m a t i s c h e

liegt nahe,

zu v e r a l l g e m e i n e r n ,

solut o p t i m a l e n

¢IK

systematische

um so v i e l l e i c h t zu kommen.

fur a u s s i c h t s ! o s

halten,

Abbauweisen

Abbauweisen

doch

ver-

noch

Um zu b e g r H n d e n ,

zu

mehr

zu einem abw a r u m wir

fHhren w i r den Begriff

der

"Ver-

zahnung"ein: Sei n die A n z a h l

der O p e r a t o r e n

KI,K2,...,K neine Streicht

Abbauweise

m a n aus M alle Knoten,

so e r h ~ i t man eine A b b a u w e i s e

des zu ~ b e r s e t z e n d e n

des

zu A g e h ~ r i g e n die n i c h t

hen ist M, von K n = E abgesehen, gibt

sich

durch

z.B.

runde

f~r die A b b a u w e i s e

Klanumern d e u t l i c h

zu T 1 bzw.

M1 von T 1 bzw.

Ausdrucks

bestHckten nicht

A und M =

Baums

(B,h).

zu T O geh~ren,

MO von T O . U m g e k e h r t

gese-

Verzahnung yon M1 mit MO. So er-

eine

des G e g e n b e i s p i e l s

gemachte

zu OV die

folgende,

Verzahnung:

(ii0,iii,ii) (O0,O1,0) (I0,i) E . Es h a n d e l t

sich

3, der d r i t t e Nur

also um 3 Zdhne; die ersten b e i d e n

die Breite

systematische

zwei sehr

wfirde j e d e n f a l l s auch,

Abbauweisen

speziel!e

(MO)~ oder M =

zu b e t r a c h t e n

Verzahnungen

(MO) (MI)E bedeuten,

~ber die Z a h n b r e i t e

besitzen

die Breite

2. bedeutet,

zu b e s c h r ~ n k e n ,

. Systematische auch m e h r

als

Vorschriften

n~mlich

Abbauweisen 2 Z~hne

zu machen.

sich

stets

auf M =

(MI)

zu v e r a l l g e m e i n e r n

zuzulassen~nd Der

auf

folgende

vielleicht Satz be-

100

gr~ndet, w a r u m wir d e r a r t i g e V e r s u c h e fur a u s s i c h t s l o s halten: Satz i0: Gibt m a n die A n z a h l m ~ 0 der Z~hne und zu jedem Zahn eine Breite b i ~ 1 vor und gilt b I ~ 2, b 2 _ > 2,..., % - 1 best~ckten Baum

> I, so gibt es einen ~ 2 und b m _

(B,h) so, dab die T e i l - A b b a u w e i s e n M1 und MO von T 1 bzw.

T O ailer o p t i m a l e n A b b a u w e i s e n M des Baums B auf die v o r g e g e b e n e Art verzahnt sind, d.h. diese V e r z a h n u n g e n sind erzwingbar. A l l e s o n s t i g e n Verza~ngen

mit b i ~ 1 fHr i = l(1)n sind nicht erzwingbar.

nahme: F~r B = { ¢ , 0 , i , 0 0 , 0 1 , I 0 , i i } Beweis:

Siehe

gilt b I = b 2 = I.

[5], Satz 25.

Es sind also n a h e z u alle V e r z a h n u n g e n erzwingbar. Meinung,

D e s h a l b sind wir der

dab man nur mit g r u n d s ~ t z l i c h neuen Ideen ein V e r f a h r e n finden

kann, w e l c h e s zu jedem b e s t ~ c k t e n und m a r k i e r t e n Baum 1 optimale Abbauweise

6. L i t i]

era

Samelson,

Nakata,

liefert.

K.', Bauer, F.L.:

I.: "On C o m p i l i n g A l g o r i t h m s

Redziejowski,R.R.: A C M 12, 81 - 84

[4]

for A r i t h m e t i c E x p r e s s i o n s " ,

"On A r i t h m e t i c E x p r e s s i o n s and Trees", Comm. (1969)

Sethi,R., U l l m a n n , J . D . :

Peters, U.:

"The G e n e r a t i o n of O p t i m a l Code for Jo~r. A C M i_~7, 715 - 728

(1970)

"Der H i l f s z e l l e n b e d a r f yon ~ b e r s e t z t e n A u s d r H c k e n " ,

Dissertation,

Institut fur A n g e w a n d t e M a t h e m a t i k und I n f o r m a t i k

der U n i v e r s i t ~ t des Saarlandes, D-66 S a a r b r ~ c k e n II

A n s c h r i f t des Verfassers: Dipl.-Math.

Comm.

(1967)

Arithmetic Expressions", [5]

"Sequential F o r m u l a T r a n s l a t i o n " ,

(1960)

Comm. A C M i_O0, 492 - 494 [3]

(B,h) m i n d e s t e n s

t u r

A C M ~, 76 - 83 [2]

Einzige Aus-

Ulrich Peters

Institut fur A n g e w a n d t e M a t h e m a t i k und Informatik der U n i v e r s i t ~ t des Saarlandes D-6600 S a a r b r ~ c k e n

ii / St. J o h a n n e r S t a d t w a l d

(1973)

A PASCAL COMPILER BOOTSTRAPPED ON A DEC-SYSTEM 10 G. FRIESLAND ~ C~O.__GROSSE-LINDEMANN~

P~W. LORENZ~

H.-H. NAGEL, P.J. STIRL

Abstract A new PASCAL (1) compiler, developed at the ETH ZGrich

(2), has been

successfully bootstrapped on to a PDP-10 within 7 months by the equivalent work of 3 students.

The approach differed from (3) insofar as no

other computer has been used during this process. conclusions

concerning the bootstrap procedure,

Our experience and

the compiler from which

we started and the language PASCAL are reported.

I Based on the experience of teaching an introductory science,

at Hamburg University

limited control and data structuring facilities guages

course in computer

since summer 1972, it was felt that the of the available

(essentially ALGOL 60 and FORTRAN IV) were insufficient

many nonnumerical programming problems.

lan-

for

The independent implementation

of a mor@ powerful language for the DEC-System 10/50 at the Institut fQr Informatik was way beyond our resources. PASCAL-Compiler written in PASCAL appear feasible

The availability of a

(1,4,5), however, made a bootstrap

- an impression reinforced by the example for the Bel-

fast ICL 1900 (3). Compared to the Belfast approach the situation at Hamburg differed in that such a project would have to be carried through by students who had no previous experience with compilers,

the

language PASCAL or the DEC-System 10 which became operational here in November 72. In addition, no trip to Z~rich could be financed nor was any other CDC-installation with a running PASCAL-compiler accessible to us at that time. We therefore

investigated a bootstrap using our PDP-IO only, based on

a PASCAL source version and a corresponding CDC 6000 object version of the PASCAL compiler

(4,5) which we obtained together with the CDC as-

sembly language runtime s u p p o ~ from the ETH ZUrich.

During the winter

term 72/73 a simulator for the CDC 6000 series was deve~ped in MACRO-10~ the DEC-System

10 assembly language.

Simulating the execution of the

102

CDC object code version of the PASCAL compiler required a special bare bones

(23 k word) monitor version, only usable during night shifts and

weekends:

our installation is equipped with only 65 k words, 56 k of

which were.required by code and working space for the CDC object version of the PASCAL compiler

(2 PDP-IO words ~ 36 bit for each 60 bit

CDC word), about 2 k words for the simulator of the CDC 6000 processor as well as the runtime support of the compiler and the remaining 4 k words were required for I/O buffers, debugging support and working space. In March 73 we succeeded in compiling the PASCAL source version of the compiler,

taking more than 90 minutes real time on a dedicated

PDP-IO - to be compared against 55 seconds to execute the same compilation on the CDC 6400 at the ETH Z~rich

(5). Since we had not yet im-

plemented the simulation of floating point instructions,

the object

code of the compiler obtained by simulation at Hamburg was not completely identical to that obtained from ZHrich. These experiences

(6) indi-

cated that a bootstrap without recourse to a faster executable

compiler

version would become rather laborious.

II Therefore we decided to bootstrap the new PASCAL compiler veloped during this period. new compiler generates

(2) being de-

In order to improve its portability

code for an hypothetical

stack computer

(7) the (SC)

rather than for the CDC 6000 series. The SC was communicated to us (8) in form of a short description and the listing of a PASCAL program to interpret SC-code.

On this basis an interpreter was written in MACRO-IO

and debugged by two students in about two weeks.

After having obtained

(April 8, !973) a magnetic tape with a PASCAL source file and a SC object code file of the new PASCAL compiler, two innocent details caused considerable work until we were able to compile the PASCAL source version by using our SC-interpreter to execute the SC object code version of the compiler. The SC relies on storing data with type-attributes real, boolean,

set, pointer,

(undefined, integer,

stack mark). These are also helpful for

runtime checks, reading stack dumps etc. The original MACRO-IO version of the SC interpreter used one PDP-IO word for the type attribute and the next one for the actual data value. This representation,

however,

required so much space for the runtime stack during compilation of the compiler that more core was required than available.

Consequently the

type attribute was packed as a 3 bit field together with data into one PDP-IO word - making it impossible to use the full word for storing,

103

e.g., a complete PDP-IO instruction. using only 59 of the 64 character representations

Moreover,

in the CDC

display code, the SC at ETH ZHrich could store entities of type SET OF CHARacters

in one 60 bit CDC-word.

This is not possible on the PDP-IO

with a word size of only 36 bits. Loading,

storing or passing variables

of type SET OF CHAR requires a two word transfer whereas the original SC version only had provisions

for one word variables.

Three principal

modifications were necessary

1. In the PASCAL source version of the compiler entities of type SET OF CHAR must be endowed with a size of 2 (words) rather than 1 (word). 2. The SC object code has to treat such objects as 2 word entities. 3. The SC object code has to generate the appropriate

code for handling

such entities.

Using the well known T-notation

(9) the steps leading to reproducibili-

ty of the PASCAL compiler generating code for the SC on our DEC-System 10 can be depicted as obtained from ZUrich

I,

c

generated at Hamburg

ZC

IpA'cAL .... > .~r ZC .. , ,,.,j ~ .o,i,ico_,io. ,) 1PA.ECAL.

,~T.., v,.,, I

IPA,.*CCAL 1

IPA CAL

.sET...~ ...o,..,]

,sc' l....

=>

:=>

tPAZCAL

,,~,,,,°,i,,c,,~,o,,,

~c]

>zEr...~,.o...,~

104

PA

ECA L

>

'.

,EC

/ / / /

IPAECAL~PAECAL

+;d;I

/CJ

Sz~,,,,.Z b,,,.,c,[ I,~E'r',,,.2 o,.,~s]

L+~'+.I .~ w,,+,.~+

M~ CRo-i~

It

took

SC o b j e c t (hatched

about

two m o n t h s t o

code before T),

a long time

sembly language. fact

that

the

it

necessary

the

SC o b j e c t

SO v e r s i o n

modifications

to reproduce

compared to writing

Modifying

entire

debug the

was p o s s i b l e

of the

the

this

object

SC i n t e r p r e t e r

c o d e was a g g r a v a t e d compiler

appears

in the code in asby t h e

as one a b s o l u t e -

ly addressed piece of code. The representation of the SC code for the compiler in the PDP-IO requires 13.0 k words + 1.5 k words for constants,

the runtime stack for

the compilation of the PASCAL compiler generating code for the SC requires 13.5 k words and the PDP-iO object version of the SC interpreter together with the necessary runtime support 2.5 k words. The execution of such a compilation requires 7-8 minutes real time on a dedicated PDP-IO:

a significant advance from the CDC 6000 simulator.

The preceeding discussion shows up to what extend portability might be hampered by implicit machine dependence.

There is another example for

this encountered during our bootstrapping process, namely the dependence on character code representation.

The PASCAL as well as the SC

version of the compiler obtained from ETH Z~rich use the 6-bit-CDC-display code whereas the DEC-System iO relies on 7-bit-ASCll ternal representation of characters.

code for in-

Immediate transfer to the 7-bit-

ASCII code would have required three groups of modifications: 1. Conventions in the ASCII representation

should be used for those

PASCAL symbols that are not contained in the subset of 7-bit-ASCII characters

available at our installation.

This problem is not quite

trivial since no single EOL ("end of line") character is available in our subset of 7-bit-ASCII,

the "end of line" being represented by

105

the sequence:

carriage return - line feed.

2. Adapting the PASCAL source version of the compiler to the new conventions.

There are several instances

in the new PASCAL compiler

where it relies explicitly on the order of the 6-bit-CDC-display code to select subranges for declaring and accessing arrays with index expressions of type CHARacter.

These instances

avoided by appropriately using the available PASCAL. however,

Most of these modifications small generalisations

can all be

language features of

are trivial editing operations;

in the logical treatment of entities

with type SET OF CHAR are required

(no modifications

are required

for the CASE statement with tagfield type CHAR). 3. The consequences

of the above adaptations have to be incorporated

into the SC object code version of the compiler. It was decided against converting the PASCAL and SC version of the compiler to 7-bit-ASCll but to wait until some agreement would have been reached with respect to handling end-of-l~ne situations

and a compiler

object version generating code for the DEC-System 10 could be reproduced correctly on our installation. in the meantime mented.

Both conditions have been fulfilled

(IO) and the conversion to ASCII is just being imple-

In the meantime we converted the ASCII input file to the SC

interpreter into CDC-display code and reconverted the output file from display code back to ASCII code.

III Parallel to these activities duce code generation

two students investigated how to intro-

for the DEC-System

10 into the compiler.

The com-

pilation process for a simple example was evaluated and only those code generation procedures were inserted that were necessary to obtain the expected PDP-10 code for this example.

Based on this experience

ing all important parts of the compiler - the main problems

- touch-

could be

identified and a time schedule for their treatment be planned.

Since

both students should not spend much more than half a year on this task and nevertheless

obtain a compiler directly executable

on our DEC-

System 10, some of the following decisions have been influenced by this condition: 1. The new compiler

(2) generates code as soon as possible, using the

runtime stack to hold results of evaluated subexpressions. respect it is similar to the first PASCAL compiler the CDC 6000 X-registers

In this

(5) which used

as a register stack. As already noted for

106

the old compiler

(3,11) this approach requires either complete re-

writing of the expression evaluating parts or accepting severe inefficiencies

in the code generated for machines that may combine

registers directly with operands in memory. vides 16 accumulators

Since the PDP-IO pro-

of which 15 may be used as index registers as

well, we could use a large fraction of these to implement a register stack - an option not open for the ICL 1900 series

(3). We decided

to do this and postpone an optimization that can only be obtained by considerable redesign of those parts analysing expressions. 2. The availability of many index registers would allow a realization of the display register concept - suggested, first PASCAL compiler

e.g., by Wirth for the

(5); it can be found, too, in the architecture

of the Burroughs B 6700 computers

(12)o Hoare observed - quoted by

Wirth in (13) - that most of the variables used in a procedure either declared locally or globally.

It seems to be more economical

to dynamically evaluate the proper environment ed at an intermediate

are

for a variable declar-

level whenever it is used rather than update

the display registers every time a procedure is left. We adopted this solution and - as a consequence

- changed the declaration of

some ra~her frequently used variables

from their original interme-

diate level to the global level. 3. Although the PDP-IO version of the PASCAL compiler should eventually generate absolute, directly executable

code, it seemed advantageous

to output the generated code during the conversion phase in the form of MACRO-IO assembly language.

The extra assembly step enabled us to

generate absolutely addressed code in the compiler and nevertheless link on the runtime support in assembly language and the DEC-System 10 dynamic debugging package in a loader run on the relocatable ject code generated by the assembler.

ob-

Since the PASCAL compiler as

received from ZUrich only had provisions

for one standard input and

one standard output file, the simultaneous

output of a compiler list-

ing and code for later execution was only possible by treating the listing as comments to the assembler

(compare later remarks on the

restriction of only one output file). 4. The byte manipulation

facilities

of the PDP-IO considerably simpli-

fied the implementation of PACKED RECORD and PACKED ARRAY ~I .. 10~ OF CHAR which enables us to use only two words to store identifiers with up to ten characters. Without implementing PACKED we would have run into core storage bottlenecks on our installation.

However,

char-

acter strings other than identifiers

are not yet packed:

this would

require a nonstandard PACK procedure

since the size of other strings

107

is only detected at execution time and not fixed in a declaration. (See later remarks.)

A detailed discussion of the decisions that resulted in the current compiler version for the DEC-System I0 can be found in (14). The bootstrap of the PDP-IO version proceeded according to the following diagram where the

[PAC4L /¢4cRo' .........

~

t PA~'~/-

....

IPA~C/4I"IPA~CAL ~

,,SC

W' assembly run (MACRO-IO into PDP-IO machine code) has been suppressed. Without

optimization of the PDP-IO code generation the compilation of

the compiler can be executed within

110 seconds of a dedicated PDP-!O,

to be compared to 600 seconds needed to obtain the same compilation by interpreting the SC version of a compiler generating code for the PDP10. Replacing the code generation for the SC by that for the PDP-IO has somewhat increased the size and compile time. The PDP-IO version requires at the moment 5 k words for runtime time support and I/O buffers,

stack, 2 k words for run-

4.5 k words for global variables,

24.5 k words for code and constants,

and

at a total of 36 k words.

The next steps are: - converting to 7-bit-ASCII

code as internal character representation;

- writing a new runtime support to provide I/0-capabilities

for arbi-

trary files, not only for the standard files INPUT and OUTPUT as in the compiler version obtained from ETH ZUrich; -

providing means to communicate via a typewriter terminal,

something

which is not asked or implemented in a batch processing environment but of great importance in a timesharing environment DEC-System 10;

as given by the

108

- output directly is immediately - optimization

executable,

absolute

code which after the compilation

loaded and started;

by redesign

of analysis

and code generation

for expres-

sions.

IV The clarity and formulating power of the p r o g r a m m i n g

language

together with the well structured

by U. Ammann have

very favourably

influenced

cope with several adverse the p a r t i c i p a t i n g

compiler developed

this b o o t s t r a p p i n g circumstances

students

nobody at our institute

had no practZcal

this b o o t s t r a p p i n g

experience

experience

in compiler

of this size;

in PASCAL or in MACRO-tO;

had seen the new compiler when we decided

on

project.

Based on the experience

gained during the realization

process we would like to discuss

some modifications

which we started in order to improve can be organized

since we had to

in a short period:

building or handling a p r o g r a m m i n g project - they had no p r o g r a m m i n g

project,

PASCAL

to the system from

its portability.

in three areas which a~e almost

of this bootstrap

Our suggestions

independent

from each

other: I. The stack computer and the SC version of the compiler. 2. The PASCAL version of the new compiler as far as no modifications to the definition 3. Considerations

of the language

PASCAL are implied.

to modify the PASCAL definition.

Ad i: Modifications

to SC and SC compiler

version

i.I The SC should not rely on word sizes greater than, e.g., internal representation 1.2 Any unavoidable

modifications

would be considerably with symbolic one absolutely ing phase"

to the SC object

code of the compiler

to labels rather than as

Since the SC employs

the character representation

representation, unreasonable

the realization overhead

anyway a "load-

of the SC code of this suggestion

(see section

the SC outputs either a compiler can be loaded and executed.

choose between two compilation

passes

II).

listing and SC code -

case the SC code cannot be loaded and executed

SC code which

32 bits for

II).

eased if the SC code could be written out

addressed block.

to convert

into its internal

in which

(see section

branch addresses referring

might not introduce 1.3 At present,

of data

This

- or only

forces the user to

or not getting e compiler

Io9

listing.

If the SC loader could recognize

a "comment" symbol and

every line of compiler listing would be preceeded by such a comment symbol,

this unfortunate

alternative

can easily be avoided.

Ad 2: Changes in the new PASCAL compiler requiring no modifications to the language definition. 2.1 The dependence

of the compiler on the order of character symbols

in the code used for internal representation explicit.

should be made more

This includes defining and initialising all arrays for

at least a full 64 character

set regardless

of its internal order-

ing. In addition the compiler logic for handling SETs should be parametrized in such a way that even transfer to the 7-bit-ASCi! code should be possible as far as it is restricted to the use of those characters that are also contained in the 6-bit-ASCl! subset. The realization of the CASE statement

in the PASCAL compiler

is a nice example that such an approach is indeed possible. 2.2 Since the majority of presently

available

computer architectures

support direct operand combinations between registers code generation for expressions

and memory~

should be delayed as long as pos-

sible to obtain enough information for the proper choice of instructions

(3). Being able to model code generation for these computers

according to better suited code generation

for an intermediate ma-

chine would considerably ease the transfer of such a compiler.

Now

one is forced to choose between complete redesign of the corresponding parts in the compiler for optimizing the generated code or to accept quite inefficient

and voluminous

code - if this ap-

proach is feasible at all.

Ad 3: Modifying the PASCAL definition to improve portability. 3.1 The new compiler - as it is obtained from Z~rich - has only the standard INPUT and OUTPUT files implemented

- necessitating out-

put of compiler listing and generated code on the same file. Incorporating the compiler listing as comments in the code output for the MACRO-IO assembler this disadvantage

somewhat.

(compare

1.3 of this section) eases

Still a high price has to be paid: as-

sembly of this output file from a compilation of the compiler itself requires

about 6 minutes on a dedicated PDP-IO

(three times

more than to compile with the PDP-IO version of the PASCAL compiler!) and about 35-40 minutes to print the resulting list with a 1100 line per minute printer.

This results from the input format

required by the MACRO-IO assembler,

namely one instruction per

line. Abusing some PASCAL features we enforced a second output file

110

in order to be able to separately write code for a s s e m b l e r input and a compiler listing t o g e t h e r with a compressed format

for the gene-

rated code. R e d u c i n g the print time by more than a factor three to less than 10 minutes d e s t r o y e d a considerable p s y c h o l o g i c a l barrier to obtain and inspect the current compiler output listing during d e b u g g i n g runs.

This p r o b l e m is b a s i c a l l y due to the fact that the current version of PASCAL allows the formatted input/output procedures

READ and

WRITE only for the standard files INPUT and OUTPUT, respectively. It should be easy to include an optional file s p e c i f i c a t i o n into these p r o c e d u r e s

in order to use t h e m for other files as well.

Al-

though it is in p r i n c i p l e possible to access other files by means of the standard procedures

GET and PUT, these are not i m p l e m e n t e d

in the new compiler from which we bootstrapped.

In addition - their

use requires more effort to obtain the f o r m a t t i n g features that are available in READ and WRITE. 3.2 As a corollary to the p r e c e e d i n g point: why are n o n s t a n d a r d procedure argument

conventions n e c e s s a r y for formatted I/O? One could

argue: the standard argument

conventions

are not general or power-

ful enough to account for a situation which apparently occurs so often that specific n o n - s t a n d a r d

conventions have to be introduced.

3.3 The r e s t r i c t e d memory c o n f i g u r a t i o n of our i n s t a l l a t i o n forced us to make use of the PACKED option at an early stage in the b o o t s t r a p process.

Here again we were r e s t r i c t e d from p a c k i n g general strings

- as they occur, e.g., in arguments to READ and WRITE - due to the narrow d e f i n i t i o n of the standard procedure

PACK which accepts only

arrays of characters with a size fixed at d e c l a r a t i o n time, 3.4 Considerable

space could be saved if it would be possible to ini-

tialize globally declared variables

at compile

time - a feature

w h i c h is available in the first PASCAL compiler on a trial basis, but not included in the revised report on PASCAL. 3.5 A l t h o u g h the PACKED RECORD feature enables one to generate a full PDP-IO i n s t r u c t i o n without recourse to assembly

language routines,

the lack of a proper t r a n s f e r function forbids to append full word instructions

and constants of type real, integer etc.

single output

file: the "variant" record concept

here since no space is available in the object field variable. as possible

onto one

cannot be used

code file for a tag-

If the language should allow to formulate

of the compiler r e q u i r e m e n t s

as much

in PASCAL itself - thus

r e d u c i n g the size of a runtime support to be d e v e l o p e d specifically for each i n s t a l l a t i o n - then t r a n s f e r procedure

of the follow-

111

ing kind is necessary: PACKEDWORD

(VAR RESULTWORD:INTEGER; no type declaration~

VAR NANEOFDATASTRUCTURE

;

POSITIONOFWORD:INTEGER); This would pick the word, the data structure

indicated by the third argument,

indicated

by the second argument

of its type - and return it as an integer obvious that a procedure same argument Moreover, assembly

applies

to standard

environment

communicate

it is important

different

call of an

to be able to

- and still access a standard

from the terminal

like GETLN,

etc. to allow formatted

I/O. Therefore

PUTLN

- as well as

(10) - as READTTY,

!/0 from terminals.

will be added to terminate

in his answer

CHR and ORD.

the READ and WRITE procedures

the other standard procedures

out a "earriage

like

to a nonstandard

over terminals

INPUT and OUTPUT file

procedure

procedures

It is

- but the

procedure.

we intend to reproduce WRITETTY

in RESULTWORD.

on the implementation

it is still preferable language

3.6 In a timesharing directly

depends

from

- regardless

return - line feed"

output

A BREAKLN

to the terminal

with-

in order to let the user type

on the same line on which a question has been

written by the program

(15).

V We thank Prof. N° Wirth and Mr. U. Ammann for the v e r y generous helpful

cooperation

project

up to the stage described

The NACRO-IO

that enabled us to smoothly advance

interpreter

(G.F.) with v e r y engaged

Behrens

contributed

heavily

support

of the compiler.

to the problems

connected

H.-H.

Brockmann

that all these System

runtime

Mr. H.-E.

10 when they accepted

like to extend our gratitude

of the SC

for the NACRO-IO

from 0DC- to ASCII-

has been developed

- a considerable

Mr. M.

Sengler has drawn our attention

piece

and debugged by Mr.

of work in v i e w of the fact

students had no experience

but for their enthusiasm

support

with the conversion

code. The CDC 6000 ~imulator

by one of the

from Mr. D. Friede.

in getting the "SET problems"

solved and sketched a preliminary version

with our

in this report.

for the SC has been developed

authors

and

whatsoever

their respective

tasks.

with the DECWe would

to them not only for their contribution

and interest

with which they engaged

112

themselves. One of the authors (H.-H. N.) gratefully acknowledges a discussion with Prof. F. Schwenkel en the subject of this report.

Literaturhinweise (I) Wirth, N., The Programming Language PASCAL: Acta Informatica I, 35 (1971) and (Revised Report) Berichte der Fachgruppe Comput~rwissenschaften der ETH ZUrich, Nr. 5 (Juli 1973) (2) ~ m a n n , U., The Nethod of Structured Programming Applied to the Development of a Compiler: Proceedings of the A~ff International Computing Symposium, Davos (4.-7. Sept. 1973) (3) Welsh, J., Quinn, C., A PASCAL Compiler for ICL 1900 Series Computers: Software-Practice and Experience ~, 73 (1972) (4) Schild, R., Implementation of the Programming Language PASCAL: Proceedings of the I. GI Fachtagung ~ber Programmiersprachen MiJ~chen ~,{arch 71 and Lecture Notes in Economics and Nathematical Systems, vol 75 (1972)~ p. I, Springer Verlag, Berlin Heidelberg - New York (5) Wirth, N., The Design of a PASCAL Compiler: Software-Practice and Experience ~, 309 (1971) (6) Brockmamn, H.-H., Friesland, G., Habermann, H.-J., Lorenz, F.-W., Nagel, H.-H., Sengler~ H.-E., Stirl, P.J., Ein PASCAL Compiler f~r die PDP 10, Bericht ~ber eine Gruppenstudienarbeit: Nitteilung Nr. 2 des Instituts f~r Informatik der Universit~t Hamburg (Mai 1973) (7) see e.g. - Poole, P.C., Waite, W.N., Portability and Adaptability: Advanced Course on Software Engineering (F.L. Bauer, ed.) and Lecture Notes in Economics and Nathematical Systems vol 81 (1973), pJ83, Springer Verlag, Berlin - Heidelberg - New York Bauer, F.L., Software Engineering: Proceedings of IFIP Congress 1971, (C.V. Freimann, ed.), North-Holland Publ. Co., Amsterdam 1972, p. 530 (8) private communications by Mr. U. Ammann and Mr. N. Wirth, see also (2) (9) Earley, J., Sturgis, H., A Formalism for Translator Interactions: C A ~ 13, 607 (1970) and the literature quoted therein (10) Wirth, N., Implementations of PASCAL in systems using character sets without control characters (ETH Z~rich, note of June 26, 1973) (revised October 30, 73) -

113

(11

(12

13 -T4) 15)

Desjardins, P., A PASCAL compiler for the XEROX Sigma 6: AC~ SIGPLAN Notices ~, No. 6, p. 37 (June 73) 0rganick, E.I., Cleary, J.G., A Data Structure Model of the B 6700 Compu~r System: Proc. S2~iposium on Data Structures in Programming Languages (J.T. Tou ~. Wegner, eds.), ACM SIGPLAN Notices ~, No. 2, p. 83 (Febr. ~I Wirth, N., On "PASCAL", Code Generation, and the CDC 6000 Computer: Computer Science Department, Stanford University, STAN-CS-72-257 (Febr.72) Lorenz, F.-W., Stirl, P.J., Diplomarbeit: Institut fttr Informatik, Hamburg (in Vorbereitung) 1973 This is modelled after a corresponding feature in the DECSystem 10 ALGOL 60 version

Anschrift des Verfassers: Professor Dr. Hans-He]imut Nagel, Institut f~r Informatik der Universit~t Hamburg, 2 Hamburg 13, Schl~terstr. 70

ERFAHRUNGEN MIT EINEM PARSER-GENERATOR FOR CHOMSKY-GRAMMATIKEN R. NOLLMANN

O. E i n l e i t u n ~ J.

Eickel

und M. Paul haben in [EP] einen A l g o r i t h m u s

der das A n a l y s e - und M e h r d e u t i g k e i t s p r o b l e m tiken untersucht. W e s e n t l i c h bei dem V e r f a h r e n i s t einer bottum-up-Analyse vornherein

vorgestellt,

bei Chomsky(-o)-Gramma-

der Gedanke, S c h w i e r i g k e i t e n

bei

dadurch zu vermeiden, da~ man sich n i c h t

auf eine bestimmte A n a l y s e - S t r a t e g i e

festlegt,

von

also i n s -

besondere auch v o n d e r Ublichen L i n k s - R e c h t s - S t r a t e g i e a b w e i c h t . Auch s o l l e n I n f o r m a t i o n e n , wie S c h w i e r i g k e i t e n zu beheben s i n d , n i c h t erst

zur L a u f z e i t

des Parsers gesammelt werden, sondern in einem

Parser-Generator-Lauf.

Die e r z e u g t e n L i s t e n

sollen

m~glichst

klein

sein. Der Parser s o l l

dabei wie f o l g t

arbeiten:

Die Analyse kann in mehreren " L ~ u f e n " d u r c h g e f U h r t werden. Dabei werden in einem " L a u f " j e w e i l s duziert,

"schwer" a n a l y s i e r b a r e

L~ufe a n a l y s i e r t

Teile

werden, wobei g e h o f f t

erkannter Teilstrukturen

Chomsky(-o)-Sprachen

analysierbare

Teile

re-

sollen

in einem der n~chsten

wird,

da~ auf Grund b e r e i t s

d i e Analyse dann weniger schwer sein w i r d .

Wegen der U n e n t s c h e i d b a r k e i t fur

nur " l e i c h t "

des Wort- und M e h r d e u t i g k e i t s p r o b l e m s

kann das V e r f a h r e n von Eickel

und Paul nur

ein Versuch s e i n , bei konkreten Grammatiken diese Fragen ( t e i l w e i s e ) beantworten zu l a s s e n . Der P a r s e r - G e n e r a t o r u n t e r s u c h t den s t r u k turellen

Zusammenhang e i n e r v o r g e l e g t e n Sprache. Dadurch e r h ~ I t

der

S p r a c h e n t w e r f e r w i c h t i g e Hinweise auf E i g e n s c h a f t e n der Sprache ( e r k a n n t e M e h r d e u t i g k e i t e n , S a c k g a s s e n f r e i h e i t bzw. - a r m u t , s t r u k t u r e l l e K o m p l e x i t ~ t ) , dem I m p l e m e n t i e r e r w i r d die K o n s t r u k t i o n der Obergangslisten erleichtert oder ganz abgenommen. W~hrend d i e Syntax von Programmiersprachen

U b l i c h e r w e i s e mit H i l f e

kontextfreier

t i k e n b e s c h r i e b e n w i r d , lassen sich mit H i l f e von a l l g e m e i n e n Chomsky-Grammatiken Optimierungen in der N~he der Q u e l l s p r a c h e auch der Z i e l s p r a c h e b e s c h r e i b e n .

Grammaals

115

1. Der Parser-Generator Der Parser-Generator untersucht den strukturellen Zusammenhang einer gegebenen Chomsky-Grammatik. Er soll dabei erkennen, ob es in der Grammatik Mehrdeutigkeiten und kritische Regeln gibt. Kritische Regeln, d.h. Regeln, die bei einer bottum-up-Analyse in Sackgassen fUhren k~nnen, sollen unkritisch gemacht werden. Der Parser-Generator transformiert dazu die Grammatik s c h r i t t weise in eine sackgassen~rmere Grammatik, indem er zu kritischen Regeln innerhalb vorgegebener Schranken Links- und/oder Rechtskontext konstruiert. 1.1 Beschreibung des Verfahrens Yon der zu untersuchenden Grammatik G = (A, T, P, S) mu8 das Produktionensystem P in BNF-Schreibweise vorliegen. Die Menge A der Alphabetelemente wird aus dem Produktionensystem bestimmt. Angaben zum terminalen

Zeichenvorrat T und zur Menge S der

Axiome sind nicht notwendig. Die Axiome sollen jedoch maximal sein, d.h. zu keinem Axiom s E S gibt es eine Produktion, so da~ gilt a::=bsd. Oberdies soll die Grammatik eine "Grammatik mit Randzeichen~ " sein. 1.1.1Zun~chst wird die folgende einfache Transformation vorgenommen: T r i t t ein Alphabetelement X(A mehr als einmal in den rechten Seiten des Produktionensystems auf, so wird fur jedes Auftreten yon X dem Alphabet ein X~A hinzugefUgt, das ( k r i t i s c h e ) Alphabetelement X wird an der Fundstelle durch das (unkritische) X' ersetzt und schlieBlich wird dem Produktionensystem P die ( k r i t i sche) Produktion X'::=X hinzugefUgt.

Die Menge der auf diese Art

erzeugten Regeln wird Menge der kritischen Regeln genannt: Regeln dieser Menge k~nnen der Beginn von Mehrdeutigkeiten oder Sackgassen sein. 1.1.2 Nach dieser einfachen Transformation wird das Alphabet in disjunkte Teilmengen zerlegt: A

:

AL

v

Ak

~

A'

~

~u

A-

A~

wobei g i l t : Az i s t die Menge der Alphabetelemente, die im Produktionensystem nut auf den linken Seiten auftreten (Axiom, Antiterminal-Elemente);

116

Ak

ist

die Menge der k r i t i s c h e n

Alphabetelemente;

A'

ist

die Menge der u n k r i t i s c h e n

Alphabetelemente,

die ein-

z i g e s A l p h a b e t e l e m e n t der r e c h t e n S e i t e e i n e r P r o d u k t i o n sind; ist

d i e Menge der A l p h a b e t e l e m e n t e ,

einer Produktion ist

A-

ist

beginnen;

die Menge der A l p h a b e t e l e m e n t e ,

einer Produktion

die eine r e c h t e S e i t e

die eine r e c h t e S e i t e

beenden;

die Menge der A l p h a b e t e l e m e n t e ,

S e i t e e i n e r P r o d u k t i o n weder e r s t e s

die

in e i n e r r e c h t e n

noch l e t z t e s

Element

sind. Mit Hilfe

d i e s e r Zerlegung l ~ B t sich die z w e i s t e l l i g e

Relation

definieren: Sei X, Y £ A. Es g e l t e

X~ Y

genau dann, wenn eine der f o l -

genden Bedingungen g i l t : I)

XE ~

~

A-,

2)

X E A~ ,

3)

Es gibt kein

Y ~ A~ Y ~ A- ~ A/ p E P, so dan g i l t :

p=(a::=alXYa2)

Mit H i l f e der Relation ~ l~Bt sich schnell und einfach prUfen, ob eine vorgelegte Zeichenreihe (String) "unzul~ssig" i s t . Diese PrUfung e r f o l g t " s t a t i s c h " , d.h. ohne reduzierendes ("dynamisches") Anwenden von Produktionen. Eine "nicht unzul~ssige" Zeichenreihe kann durch (mehrmaliges)

Reduzieren als "syntaktisch falsch" er-

kannt werden. Der Analysealgorithmus prUft bei zwei benachbarten Alphabetelementen j e w e i l s , ob die Relation ~ e r f U l l t i s t oder nicht. Diese PrUfung i s t besonders nach k r i t i s c h e n Reduktionen w i c h t i g , um unzul~ssige Zeichenreihen zu eliminieren. 1.1.3 Mit Hilfe was ein a)

der Zerlegung des Alphabetes l ~ B t "offener"

bzw. ein

sich l e i c h t

"abgeschlossener" String

sagen,

ist:

Ein S t r i n g X = X l . . . XnEA + (A+: f r e i e Halbgruppe Uber A b z g l . der K o n k a t e n a t i o n ) h e i B t o f f e n , wenn (mindestens) eine der f o l g e n d e n Bedingungen e r f U l l t a.1)

XIE Ai ~ A-

a.2)

Xn~A- v

Ax.

ist:

117

b)

Ein S t r i n g

C)

Ein S t r i n g

x ~ A+

h e i B t abgeschlossen, wenn x£ (AZ) + g i l t .

X:XlooOXnEA+

heiBt links

(rechts)

abgeschlossen,

wenn XI~A± (Xn~A x) g i l t . Nun wird e i n " R e d u k t i o n s s c h r i t t I)

f u r einen S t r i n g "

FUhre in dem zu a n a l y s i e r e n d e n S t r i n g

(von l i n k s

oder umgekehrt gehend) an j e d e r S t e l l e , kritische

Reduktion mSglich i s t ,

erkl~rt: nach r e c h t s

an der eine n i c h t -

diese Reduktionen aus.

F a l l s der S t r i n g dann weder o f f e n noch abgeschlossen i s t mindestens eine n i c h t - k r i t i s c h e wiederhole I). 2)

Reduktion m~glich war,

Andernfalls:

FUhre an j e d e r m~glichen S t e l l e ,

an der eine k r i t i s c h e

t i o n m~glich i s t ,

Reduktionen aus. Z~hle den

die k r i t i s c h e n

R e d u k t i o n s z ~ h l e r dieses S t r i n g s 3)

und

um I hoch.

Reduziere in jedem der r e d u z i e r t e n S t r i n g s an der eine n i c h t - k r i t i s c h e

Reduk-

an j e d e r S t e l l e ,

Reduktion m~glich i s t .

Wiederhole

bei jedem der U b r i g b l e i b e n d e n n i c h t u n z u l ~ s s i g e n S t r i n g s nicht-kritische

Reduktionen, b i s der S t r i n g entweder o f f e n

oder abgeschlossen i s t

oder b i s keine w e i t e r e n i c h t - k r i t i s c h e

Reduktion mehr m~glich i s t . Bern. :

Im T e i l s c h r i t t

2) entstehen h ~ u f i g S t r i n g s ,

der R e l a t i o n

~

werden mUssen. Deshalb i s t

der T e i l s c h r i t t

Einsparung von Speicher besonders w i c h t i g . z.B.,

wenn f u r

i

kritische

Ersetzungen m~glich s i n d , 1.1,4 Z i e l

des Verfahrens

ist

bedingungen zu f i n d e n .

bedeuten, dab

3) wegen der Es entstehen

Elemente j e w e i l s

kl'k2"...'ki

es, zu k r i t i s c h e n

K. 1 neue S t r i n g s .

Produktionen

Kontext-

Die Schreibweise >

sol]

die auf Grund

u n z u l ~ s s i g sind und deshalb e n t f e r n t

X

zu

X'

x

reduziert

werden kann, wenn der

L i n k s k o n t e x t a E A+ und der R e c h t s k o n t e x t bE A+ vorhanden i s t ; dann kann

aXb zu aX'b

Das gewUnschte Z i e l

und

ist

aX'b

erreicht,

zu x ~

A+ r e d u z i e r t

wenn es zu dem L i n k s k o n t e x t a

und dem R e c h t s k o n t e x t b nur eine anwendbare k r i t i s c h e X'::=X gibt. Aus der ( u n e n d l i c h e n )

werden.

Produktion

Menge m ~ g l i c h e r , im Sinne der R e l a t i o n

n i c h t u n z u l ~ s s i g e r K o n t e x t e w i r d genau ein Element ausgew~hlt:

118

O.B.d.A sei x=XI...X n rechts offen, d.h. an x kann rechts Kontext angefUgt werden. Dann gibt es n~mlich ein Y ~ A und eine Produktion p ( P, so dab p=(a::=alXnYa2) (und damit auch Xn ~ Y) g i l t . Dann i s t Ya2 der gesuchte Kontext. {Dieser Kontext wird gelegentlich auch Grundkontext genannt, im Gegensatz zu den Kontexten, die sp~ter auf andere Art k o n s t r u i e r t werden.) Linkskontext wird analog gefunden. Nach dem Anh~ngen yon Kontext hat man Strings, die weder offen noch abgeschlossen sind. Durch weitere Reduktionsschritte fur Strings wird versucht, sie zu offenen oder abgeschlossenen Strings zu reduzieren. Die I t e r a t i o n s v o r s c h r i f t zur Kontextsuche fur die k r i t i s c h e Produktion X'::=X l a u t e t demnach (ohne Abbrech-Kriterium):

~i]

X'::=X

[bi]

~

xi

I

~

fur i = 0 , i , 2 . . . . .

[ai+ ~ X'::=X [ b i + 1 ] - - - > wobei ao:=e,

bo:=e

und

Xo::X~

xi+ 1

zu setzen i s t (e i s t der leere

String).

Es g i l t : I

a ~i + l a i

falls

xi

links offen

ai

falls

xi

links abgeschlossen und noch kein Randzeichen angefUgt {~t

ai

sonst

ai+l =

bi+l

bi b' i+I

falls

xi

rechts offen

bi ~

falls

xi

rechts abgeschlossen und noch kein Randzeichen angefUgt i s t

bi

sonst

119

falls

links

xib~ i + l

falls

rechts

a' i + i x i b ~ i÷i

falls

links

xi

sonst

a'i+lX i

Xi+l

1.1.5

offen

offen und r e c h t s

Wir haben im l e t z t e n A b s c h n i t t a n g e d e u t e t , wann d i e zu einem k r i t i s c h e n Element beendet werden kann. Zun~chst

sagen w i r ,

zwei S t r i n g s

a)

was u n t e r

Kontextsuche

und R e c h t s d u r c h s c h n i t t verstanden

XflLy

: :

e

falls

j = o

x

falls

j : n

y

falls

j : m

x ...xj i

sonst

Linksdurchschnitt

Dann h e i B t

I

in

yon x und y.

Sei j d i e maximale Anzahl d e r j e n i g e n A l p h a b e t e l e m e n t e , denen x und y vom Ende her Ubereinstimmen.

xr~Ry : =

von

werden s o l l :

Sei j die maximale Anzahl d e r j e n i g e n A l p h a b e t e l e m e n t e , denen x und y vom Anfang her Ubereinstimmen. Dann h e i B t (e sei der l e e r e S t r i n g ) I

b)

Links-

x : X I . . . X n und y = Y l . . . Y m

offen

F e

falls

j = o

x

falls

j = n

y

falls

j = m

Xn_j+l...x Rechtsdurchschnitt

n

von x und y .

sonst

in

120

Damit lassen s i c h d i e f o l g e n d e n D e f i n i t i o n e n c)

geben:

Die Kontextabh~ngigen P r o d u k t i o n e n

[c] Y'::=Y ~ ] - - - > y heiBen kompatibel, wenn die folgenden Bedingungen gelten:

d)

c.i)

x = v

C.2)

X~ Y~

C,3)

ar~Rc = a

oder

a ~R c :

c.4)

b ~L d = b

oder

b nLd : d

Eine k o n t e x t a b h ~ n g i g e P r o d u k t i o n ihr

e)

keine k o m p a t i b l e

c

heiBt eindeutig,

kontextabh~ngige Produktion

wenn es zu gibt.

Eine kontextabh~ngige Produktion [a] X ' : : = X [ b ] - - - ~ x ' ,

x'~(A~) +

heist mehrdeutig, wenn es zu i h r eine kompa t i b l e kontextabh~ngige Produktion [a']X'~::=X [b']---~ x ' ' ,

x''E(A L) +

gibt. f)

Eine kontextabh~ngige Produktion heiBt k r i t i s c h , wenn sie weder eindeutig noch mehrdeutig i s t ,

Damit k~nnen w i r sagen: Die Kontextsuche zu e i n e r k r i t i s c h e n als e i n d e u t i g

Produktion

oder mehrdeutig e r k a n n t

Wegen der g e n e r e l l e n U n m ~ g l i c h k e i t ,

e n d e t , wenn sie

ist,

einen A l g o r i t h m u s

anzugeben,

der das Wort- bzw. das M e h r d e u t i g k e i t s p r o b l e m f u r ChomskySprachen l ~ s t , wird bei E r r e i c h e n der vorgegebenen Schranke f u r d i e K o n t e x t l ~ n g e oder f u r d i e Anzahl der R e d u k t i o n s s c h r i t t e f u r S t r i n g s d i e Kontextsuche zu der b e t r e f f e n d e n k r i t i s c h e n P r o d u k t i o n eingestellt. Diese P r o d u k t i o n kann also bei sp~teren P a r s e r l ~ u f e n in Sackgassen ( " b a c k - u p " )

oder in M e h r d e u t i g k e i t e n

fUhren.

!21

1.1.6 I s t fur alle kritischen Produktionen die Kontextsuche beendet worden, so i s t es notwendig, den gewonnenen Kontext zu begutachten, um notwendigen yon unn~tigem Kontext zu unterscheiden+ Nicht notwendiger Kontext einer kontextabh~ngigen Produktion kann gestrichen werden. Er wUrde den Parser nur belasten. Notwendig soll ein Kontext dann sein, wenn er gerade noch sichert, dab die kontextabh~ngige Produktion nicht kompatibel wird. Ein einfacher Ansatz zu einer Kontextverminderung ergibt sich aus folgender Oberlegung: Zu der kontextabh~ngigen Produktion

jail

Xi::=X[bi]

>

xi

betrachte man die Rechtsdurchschnitte ai ~Ral und die Linksdurchschnitte bi ~Lbj mit allen kontextabh~ngigen Produktionen [aj] Xj::=X[bj] fur die

Xi $ Xj

,, x j ,

gilt.

Unter diesen Rechts- und Linksdurchschnitten w~hlt man die j e weils l~ngsten aus, z.B. a j l und bj2. Dann g i l t ( Ixl bedeute L~nge von x ) :

Falls

lajll

<

laii

_

Aiai( i )I )

(a i = A i ) . . .

gilt,

t

ist

ai = A( i )

la+l

) ein . . . A I~ d

laj l

kUrzerer Linkskontext und, ,+,++

<

Ibil

'

- i

(bi

Ibj21 +I

i s t bi = B i) '" . B(i) Rechtskontext

zu

=

B~i)...

B~i) )

gilt,

ein kUrzerer

Xi::=X.

(Es lassen sich weitere Kontexteinschr~nkungen angeben.) Durch die Kontextverminderung werden m~glicherweise identische kontextabh~ngige Produktionen erzeugt, diese werden bis auf eine kontextabh~ngige Produktion gestrichen.

122

1.1.7

Die b i s h e r e r z e u g t e n Kontexte sind G r u n d k o n t e x t e , die bei o f f e n e n S t r i n g s durch Erg~nzen von Alphabetelementen aus Produktionen entstanden. Fall

eintreten,

Bei der sp~teren Analyse kann jedoch der

dab zu einem k r i t i s c h e n

G r u n d k o n t e x t vorhanden i s t mente zu f i n d e n s i n d , kontext nicht

durch

kritische

Ele-

zu denen wiederum der b e n ~ t i g t e Grund-

n~mlich der G r u n d k o n t e x t durch d i e j e -

"anderen" k r i t i s c h e n

Situation

und an s e i n e r S t e l l e

kein

gefunden w i r d .

In diesen F ~ l l e n wird weils

Alphabetelement

Elemente e r z e u g t .

und U n v o l l s t ~ n d i g k e i t

"Falten"

Diese " d e a d - l o c k " -

des Produktionensystems

der vorhandenen Grundkontexte b e s e i t i g t

soll werden:

Seien

[a] ×'::=X [BI... Bj Bj+I"'" B ] und

[C1.,. Ci Ci+1.. " Cm] yi::=y [d] ~ - - - >

zwei k o n t e x t a b h ~ n g i g e

[a]

(d.h. X':::X

y

Produktionen.

Wenn es eine P r o d u k t i o n gibt

~ x

p mit p = ( a o : : = a i C i B j + l a 2 )

Ci ~ Bj+ I g i l t ) ,

dann i s t

~I.,.BjCi+I...CmYd]-=-->aX'BI...BjCi+I...CmY'd

ein w e i t e r e r

Kontext zu X ' : : = X .

Ein w e i t e r e r

K o n t e x t zu Y ' : : = Y

[aXBI...BjCi+I...Cm]

Y':::YEd]

ist ) a×'BI...BjCi+I...CmY'd.

1 . 1 . 8 Die im l e t z t e n S c h r i t t e r z e u g t e n Kontexbedingungen ( " F a l t u n g e n " ) werden m ~ g l i c h s t g e k U r z t und m i t den b i s h e r gewonnenen Kontexten verglichen,

Wurden K o n t e x t e mehrfach e r z e u g t ,

so werden s i e bis

auf ein Exemplar g e s t r i c h e n . Wurden k o m p a t i b l e

Kontexte e r z e u g t ,

so wird

f u r d i e s e Elemente

w e i t e r e r K o n t e x t g e s u c h t . Das e r w e i t e r t e Kontextsystem w i r d weiterhin gefaltet, bis entweder durch F a l t e n keine neuen Kontexte e r z e u g t werden oder die b e r e i t s werden.

genannten Schranken e r r e i c h t

123

1.2 Schwierigkeiten Bisher wurden die wesentlichen Teile des Algorithmus

be-

schrieben. Bei der Implementierung des Generators traten f o l gende Probleme auf: a)

Wie kann der Speicher- und Zeitbedarf klein gehalten werden?

b)

Wie wird die Kontextsuche zweckm~Big gesteuert? (Bisher wurde l e d i g l i c h gesagt, da~ zu kompatiblen kontextabh~ngigen Produktionen Kontext gesucht wird.)

c)

Wie sollen zyklische Reduktionen und zyklische Kont~xte behandelt werden?

1.2.1Bei der Beschreibung eines Reduktionsschrittes fur einen String wurde bereits gesagt, yon welcher Gr~Benordnung die Anzahl der Strings i s t , die durch Ersetzung k r i t i s c h e r Alphabetelemente entstehen. Die angegebene Reduktionsvorschrift s t e l l t sicher, dab gerade diese kritischen Reduktionen unter Kontrolle bleiben. Nicht-kritische Ersetzungen sind (sofern sie nicht zyklisch zu l~ngeren reduzierten Strings fUhren) unbedeutend fur den Speicherbedarf. Das bisher p r a k t i z i e r t e Verfahren, alle m~glichen kritischen Reduktionen auszufUhren, i s t einfach, aber speicheraufwendig:

Ein menschlicher "Reduzierer" "sieht" viel

h~ufiger, wo eine oder auch mehrere kritische Reduktionen nUtzlich sein k6nnten. Der Mensch l e r n t aus der vom Generator ausgegebenen Reduktions-"Geschichte", welche kritischen Reduktionen ausgew~hlt werden mUssen, um Verzweigungen der Reduktion zu vermeiden. Der Reduktionsalgorithmus wird im wesentlichen so m o d i f i z i e r t : Sind bereits eindeutige oder mehrdeutige kontextabh~ngige Produktionen erkannt, so k6nnen sie angewendet werden, f a l l s an der Anwendungsstelle der entsprechende Kontext gefunden wird. Andernfalls mUssen wiederum a l l e m~glichen F~lle "durchprobiert" werden oder aber der menschliche Berater wird gefragt. Die Tatsache, dab alle M6glichkeiten "durchprobiert" werden, weist darauf hin, dab das System von Kontextbedingungen (noch) unvollst~ndig i s t . Es i s t w~hrend der Grundkontextsuche sehr unvollst~ndig, durch die (m~glicherweise fortgesetzten) Faltungen soll dann eine Vervollst~ndigung erreicht werden.

124

Die V o l l s t ~ n d i g k e i t ist

des (kontextabh~ngigen)

Voraussetzung f u r

seine Verwendbarkeit

Produktionensystems im Parser.

Denn

wird bei v o l l s t ~ n d i g e m Produktionensystem zu einem k r i t i s c h e n Alphabetelement kein entsprechender Kontext gefunden, so i s t der zu analysierende S t r i n g s y n t a k t i s c h f a l s c h . 1.2.2 Es i s t s i c h e r l i c h n i c h t s i n n v o l l , zu a l l e n kompatiblen k o n t e x t abh~ngigen Produktionen weiteren Kontext zu suchen, wie es etwa durch die Symmetrie der R e l a t i o n "Kompatibel" nahegelegt w i r d . Bei der weiteren Kontextsuche i s t der b e r e i t s vorhandene Kontext zu b e r U c k s i c h t i g e n .

Seien ki :: ~ i ] Xi:::X [bi] ~ x i (i~2) kompatible kontextabh~ngige Produktionen. Man bestimme die Mengen

]ki:a nRai:a "

K':= [k I K": =

[k

I

kj:bnLbj=b}

]ki:a /~IRai=a v ]kj:b {~Lbj:b }

Die Menge K' kann aufgefaSt werden als Menge k o m p a t i b l e r Produktionen m i t " u n t e r e n t w i c k e l t e m " Kontext, die Menge K" als Menge kompa t i b l e r Produktionen mit " a n d e r s " , h~ufig "gegenl~ufig" Beispiel:

entwickeltem

1) Zu

Kontext.

[BC]X~::=X[DE]~

x ~ ist x"

i°e

Produktion mit unterentwickeltem Kontext. 2) In den kompatiblen

Produktionen

[~X'::=X[e]

~

x ' und

[ e ] X " : ::X ~ ]

-----~ x"

sind die Kontexte gegenl~ufig AIs gUnstig hat sich erwiesen, zuerst weiterzuentwickeln:

entwickelt.

die u n t e r e n t w i c k e l t e n

Kontexte

!25

Falls

K' ~ ~

gilt,

so suche man nur f u r d i e

kompatiblen Produktionen aus andernfalls aus

K'

Kontext;

f u r d i e kompatiblen Produktionen

K"

Durch d i e s e V e r f a h r e n s w e i s e kann e b e n f a l l s der S p e i c h e r b e d a r f v e r m i n d e r t werden, w e i l Elementen aus 1.2.3

K'

kritische

bzw.

K"

Reduktionen nur bei den

d u r c h g e f U h r t werden.

Z y k l i s c h e Reduktionen und z y k l i s c h e Kontexte werden r i g o r o s behandelt:

Sobald eine z y k l i s c h e Reduktion oder ein z y k l i s c h e r

Kontext e r k a n n t w i r d , w i r d d i e b e t r e f f e n d e k r i t i s c h e entfernt,

wobei a l l e r d i n g s

system zu den k r i t i s c h e n nicht vollst~ndig

Produktion

v e r m e r k t w i r d , dab das K o n t e x t -

Produktionen

X.::=X m~glicherweise 1

wird.

Die Grundkontexte e n t s t e h e n auf z i e m l i c h e i n f a c h e A r t durch "~ffnen" ist

und "Kontextanh~ngen"

erreicht,

wenn nurmehr d i e Randzeichen erg~nzt werden

k~nnen. Das h e i s t aber, es s o l l ob es Kontexte ~a]

a

und

X'::=X

nicht entscheidbar. Zyklen g e f r a g t w i r d ,

1.2.3oi

b

v e r s u c h t werden, f e s t z u s t e l l e n ,

gibt,

[b ~]

Das Analyseproblem i s t

ziert

Das Ende d i e s e r Kontextsuche

so dab g i l t :

~ ~ z @ ,

aber f u r

z ~ (A~) +

a l l g e m e i n e Chomsky-Grammatiken

Dies wird h i e r nochmals erw~hnt, w e i l ob

u

zu

xuy

bzw.

xuy

zu

u

bei

redu-

werden kann.

Ein S t r i n g Linkskontext

a' E A'x(A'-) +

(bzw. b ' £ ( A - ) + xA')

heiBt z y k l i s c h e r

( R e c h t s k o n t e x t ) , wenn bei der Kontextsuche der

Linkskontext

a = a'

a ~ a"

(bzw. der R e c h t s k o n t e x t

b = b"b'b')

gefunden w i r d . Bei Chomsky-Grammatiken von Typ 2 und 3 bedeutet das, da~ es durch w e i t e r e s Uffnen die M ~ g l i c h k e i t g i b t , a l s Kontext anzufUgen.

Die M ~ g l i c h k e i t ,

wiederum

a'

(bzw, b ' )

bei e i n e r Verzweigung

immer wieder Kontext anfUgen zu k~nnen, v e r h i n d e r t

die ab-

schlieBende Reduktion a l l e r

z E (AZ) +

Verzweigungen auf ein

A n d e r e r s e i t s ergeben K o n t e x t e , d i e e r s t g a ~ n i c h t in den Zyklus fUhren oder aus ihm h e r a u s f U h r e n , n i c h t - k o m p a t i b l e n Kontexte.

h ~ u f i g d i e gewUnschten

126

Bei den anderen Typen von Chomsky-Grammatiken wird ohne RUcks i c h t auf d i e V o l l s t ~ n d i g k e i t

des erzeugten Systems von

Kontextbedingungen d a r a u f v e r z i c h t e t ,

Kontextbedingungen

w e i t e r z u e n t w i c k e l n , d i e mehr als einen Zyklus e n t h a l t e n . 1.2.3.2

Z y k l i s c h e Reduktionen, d i e keinen z y k l i s c h e n Kontext erzeugen, t r e t e n bei Chomsky-~ und -3-Typ-Grammatiken nur a u f , es zu einem

met

Ixil

X

: I

eine R e d u k t i o n s f o l g e

X--~ X1-->

...

Xn---~X ( n ~ l )

y'

weiterhin

gibt.

Werden bei Chomsky-O-Grammatiken S t r i n g s

x

x = x I Xx'x I x 2 oder x = X l y I y ' Y x 2 m i t x ' £ (A-) + x A~, X~A k , y ' ~ A \ x ( A - ) + ,

Y~A k

erzeugt,

falls

so wird angenommen, da# sich

x'

mit

bzw.

z y k l i s c h erzeugen l ~ B t . W e i t e r h i n w i r d angenommen, da~ d i e j e n i g e n Reduktionen, d i e nicht

in den Zyklus fUhren oder nach einmaligem D u r c h l a u f aus

ihm herausfUhren, genUgend I n f o r m a t i o n Uber d i e K o n t e x t bedingungen geben k~nnen. 1.3 Bemerkungen

zum Generator und zum erzeugten P r o d u k t i o n e n -

system Der G e n e r a t o r l a u f w i r d in v i e r F ~ l l e n w i l l k U r l i c h I)

Falls

"zyklische"

Reduktionen a u f t r e t e n ,

beeinfluBt:

wird die be-

treffende M~glichkeit eliminiert. 2)

Falls

"zyklischer"

Kontext a u f t r i t t ,

wird die b e t r e f -

fende M ~ g l i c h k e i t e l i m i n i e r t . 3)

F a l l s e i n R e d u k t i o n s z ~ h l e r eine vorgegebene Schranke erreicht,

w i r d d i e w e i t e r e Kontextsuche zu dem b e t r e f f e n d e n

Element e i n g e s t e l l t . 4)

Falls

eine K o n t e x t l ~ n g e

gebenen Wert e r r e i c h t , zu dem b e t r e f f e n d e n

( lal

+

Ibl

)

einen v o r g e -

wird e b e n f a l l s die Kontextsuche

Element e i n g e s t e l l t .

Durch diese MaBnahmen w i r d s i c h e r g e s t e l l t ,

dab der G e n e r a t o r -

l a u f f u r eine zu untersuchende Grammatik beendet wird und dab der S p r a c h e n t w e r f e r n U t z l i c h e Hinweise auf M~ngel der Sprachbeschreibung e r h ~ I t .

127

1.3.1 Durch die e r s t e n beiden MaBnahmen wird m ~ g l i c h e r w e i s e die Vollst~ndigkeit stellt.

des erzeugten Produktionensystems in Frage ge-

Die Frage, welche Auswirkungen das E l i m i n i e r e n h a t ,

kann der S p r a c h e n t w e r f e r ( v i e l l e i c h t ) Insbesondere i n t e r e s s i e r t

beantworten.

d i e Frage, ob das e r z e u g t e k o n t e x t -

abh~ngige Produktionensystem m ~ g l i c h e r w e i s e v e r s c h i e d e n e T e i l Produktionensysteme e n t h ~ I t , strategie-

die - mit geeigneter Analyse-

ein v o l l s t ~ n d i g e s

Produktionensystem ergeben.

F a l l s man e i n solches T e i l s y s t e m ausw~hlen k~nnte, w~re das Eliminieren unbedenklich.

Das Problem i s t

Chomsky-Grammatiken u n e n t s c h e i d b a r k e i t des Wortproblems).

jedoch f u r a l l g e m e i n e

(wegen der U n e n t s c h e i d b a r -

Bei P a r s e r l ~ u f e n w i r d h ~ u f i g b e o b a c h t e t ,

dab Regeln redundant s i n d ; d i e Redundanz b e z i e h t s i c h jedoch s t e t s auf d i e gew~hlte A n a l y s e s t r a t e g i e . Bei anderen A n a l y s e s t r a t e g i e n k~nnen andere Regeln redundant sein. 1.3.2 Der R e d u k t i o n s z ~ h l e r z ~ h l t w~hrend des G e n e r a t o r l a u f s , w i e v i e l e Reduktionsschritte fur kompatibler

Strings

(s.

1.1.3)

Kontext f u r eine k r i t i s c h e

n~tig sind,

bis n i c h t -

Produktion e r r e i c h t

ist.

Die Werte der R e d u k t i o n s z ~ h l e r erlauben eine Aussage Uber den strukturellen (In

Zusammenhang der zu untersuchenden Sprache.

[ E l w i r d eine Grammatik " s t r u k t u r e l l

nannt, wenn es Sackgassen g i b t ,

d.h.

d i e n i c h t auf ein Axiom f U h r e n . ) - ausgehend von den k r i t i s c h e n also s t r u k t u r e l l

generieren.

ge-

Und zwar weisen die Reduk-

t i o n s z ~ h l e r w e r t e auf den Aufwand h i n , freie,

zusammenh~ngend"

es g i b t R e d u k t i o n s f o l g e n , der notwendig war, um -

Produktionen - eine sackgassen-

n i c h t zusammenh~ngende Grammatik zu

Die R e d u k t i o n s z ~ h l e r w e r t e k~nnen auch auf d i e An-

zahl der K o n t e x t m ~ g l i c h k e i t e n h i n w e i s e n , d i e zu e i n e r k r i t i s c h e n P r o d u k t i o n zu f i n d e n s i n d . Bezogen auf den S p r a c h e n t w e r f e r bedeutet das, dab er den Aufwand bei der Analyse von S~tzen oder Programmen absch~tzen kann. Er kann insbesondere extrem groBen Aufwand bei e i n z e l n e n Sprachk o n s t r u k t i o n e n an besonders hohen Werten der entsprechenden R e d u k t i o n s z ~ h l e r erkennen.

128

1.3.3 Neben der Anzahl der Kontexte zu einer k r i t i s c h e n Produktion geben die Kontextl~ngen Hinweise auf den Analyseaufwand. Der Sprachentwerfer erh~It Angaben zur Kontextabh~ngigkeit einzelner syntaktischer Konstruktionen, die er in didaktischer Hinsicht als Frage nach der Erlernbarkeit der Sprache i n t e r pretieren kann. Und zwar i s t der Lernaufwand umso gr~Ber, je kontextabh~ngiger

die Sprachkonstruktionen

sind. Zu lange

Kontextbedingungen wie auch zu v i e l e verschiedene Kontextbedingungen r e c h t f e r t i g e n aus didaktischen GrUnden, den Entwurf abzulehnen. (ALGOL60 hat Kontextl~ngen yon etwa 1-2 syntaktischen Zeichen rechts und/oder l i n k s . )

1 . 3 . 4 Wird in den F ~ l l e n so g i b t

3) und 4) die Kontextsuche abgebrochen,

es neben den g e k l ~ r t e n

ein-

und mehrdeutigen Regeln

k r i t i s c h e Regeln. Ein P r o d u k t i o n s s y s t e m mit k r i t i s c h e n Regeln i s t zwar v o l l s t ~ n d i g ( f a l l s keine M b g l i c h k e i t e n nach i) oder 2) e l i m i n i e r t w u r d e n ) , abet es i s t Programmiersprache

fraglich,

tauglich

ob der u n t e r s u c h t e Entwurf e i n e r

ist~

Vorhandene M e h r d e u t i g k e i t e n sind zu u n t e r s u c h e n , ob s i e auf andere A r t , z~B. durch semantische Regeln, e l i m i n i e r b a r s i n d .

1.4 B e i s p i e l Als B e i s p i e l

werde die T e i l g r a m m a t i k

fur

arithmetische

Aus-

drUcke aus ALGOL60 g e w ~ h l t : T::= F

I T

x

F

F::=V

I(

S )

S::= T

I S +

T

E: := S

Auf d i e s e Ausgangsgrammatik

bezogen l a u t e t

das E r g e b n i s :

129

[+]

T ::= F

[(]

T:::F

[.]

T

::F

T

::=

T x F

F

::=

V

F::=(S)

[(]

s::=T

[I]

[(1 [~]

~ := T s::= T

[+1

[+]

[~]

s::=

~

[.]

s ::=s+

TIll

s ::oS+T[+] s ::= s ÷ T F ~ ]

E:::

s

[.1

2. Der erzeugte Parser Der Parser b e s t e h t aus einem f e s t e n und einem v a r i a b l e n T e i ! : Der f e s t e T e i l Teil

beschreibt die Analysevorschrift,

der v a r i a b l e

e n t h ~ I t das vom P a r s e r - G e n e r a t o r erzeugte P r o d u k t i o n e n -

system. Das erzeugte kontextabh~ngige Produktionensystem l ~ B t sich auf v e r s c h i e d e n e Arten l e s e n .

Dadurch kann der Parser in der A r t ,

wie er d i e Kontextbedingungen abzuprUfen h a t ,

b e e i n f l u B t werden.

Nach der b i s h e r i g e n A n a l y s e s t r a t e g i e wird eine Z e i c h e n r e i h e daraufhin geprUft,

ob die R e l a t i o n

benachbarte Alphabetelemente g i l t , Stellen,

an denen ein R e d u k t i o n s s c h r i t t

Reduktionen a u s g e f U h r t . "Lauf" ist.

~ fur je

x9

m6glich i s t ,

Das Ergebnis wird

genauso w e i t e r b e a r b e i t e t ,

Eine m o d i f i z i e r t e

zwei u n m i t t e l b a r

und es werden an a l l e n diese

in einem w e i t e r e n

bis es auf ein Axiom r e d u z i e r t

Strategie ist

nun, d i e Zeichen der

l i n k e n S e i t e a l s n~chste zu v e r a r b e i t e n d e Alphabetelemente anzusehen. Dieses V e r f a h r e n ~ h n e l t dem K e l l e r p r i n z i p . diese S t r a t e g i e werden "L~ufe" e i n e r angewendeten P r o d u k t i o n

gespart.

Durch

+

/

/x

x

x

+

x

+

+

x

f I/~'u~ S +.+.+ ~~ ' ' ' ' l / - ' " ''n

+

+

x

+

d+

~..

I N +

I

I

~

/

#

I

+

.~

l

#+

/~

#

+

/~

J+

+

,z__~

/

~

i

+

+

~

~.

+

N+

I

~

s

j+

v

+

X

+

<:

+

+

_~ !-. - ~ _ _ .~

~

0

131

3. Weitere E n t w i c k l u n g Es wurde an v e r s c h i e d e n e n S t e l l e n

angedeutet,

da5 e i n i g e

S c h w i e r i g k e i t e n von einem menschlichen B e r a t e r g e s c h i c k t e r behoben werden k~nnten. M i t H i l f e eines d i a l o g f ~ h i g e n Gener a t o r s kann v e r s u c h t werden, a u f t r e t e n d e S c h w i e r i g k e i t e n durch g e z i e l t e , v o n d e r im Generator vorgegebenen S t r a t e g i e abweichende MaBnahmen s c h n e l l e r

und v i e l l e i c h t

beheben. Durch e i n Dialogsystem

k~nnen so auch Hinweise ge-

wonnen werden, wo im G e n e r a t o r a l g o r i t h m u s m~glich s i n d . Durch die M ~ g l i c h k e i t ,

besser zu

Verbesserungen

mit dem Generator einen Dialog

zu

fUhren,

hat der S p r a c h e n t w e r f e r Uberdies d i e M ~ g l i c h k e i t ,

schnell

seinen Entwurf abzu~ndern.

Grammatik

ist

es l e d i g l i c h

n~tig,

Bei e i n e r Anderung der die Auswirkungen der

ge~nderten T e i l e zu beobachten; ein N e u s t a r t des Generators i s t bei k l e i n e n Anderungen zu k o s t s p i e l i g . Der P a r s e r - G e n e r a t o r wurde in der n i e d e r e n Programmiersprache PS440 i m p l e m e n t i e r t anlage TR440. Die vom h i e r sollen

a]s

und l ~ u f t

vorgestellten

(m~gliche)

auf e i n e r T e l e f u n k e n - R e c h e n -

Parser-Generator

Parser im T e i l p r o j e k t

e r z e u g t e n Parser "Compiler-er-

zeugende Systeme" des S o n d e r f o r s c h u n g s b e r e i c h s werden.

49 verwendet

132

Literatur [EP]

J. Ei c k e l ,

The Parsing and Ambiguity Problem f o r

M. Paul

Chomsky-Languages i n : Proc. of the IFIP Work, Conf. on Formal Language D e s c r i p t i o n Languages ed.: T.B. S t e e l , North Holland Publ. Comp., 1965

E ]

IN1]

J, Eickel

Transformation formaler Sprachen im H i n b l i c k auf s y n t a k t i s c h e Analyse B e r i c h t 5708, Mathem. I n s t . der TH MUnchen, 1967

R. Nollmann

Zur Transformation von Grammatiken nach einem Algorithmus yon Eickel und Paul, D i p l o m a r b e i t , Mathem. I n s t . der TH MUnchen,

IN2]

R. Nol Imann

IN3]

R. Nol Imann

1968

Zur Optimierung des Verfahrens von Eickel und Paul zur Transformation von Grammatiken B e r i c h t 7007, Mathem. I n s t . der TH NUnchen, 1970 CHOMSKY-Ein Programm zur Bearbeitung des Analyse- und Mehrdeutigkeitsproblems bei Chomsky-Sprachen I n t e r n e r B e r i c h t , Mathem. I n s t . der TU MUnchen, Juni 1972

Anschrift

des V e r f a s s e r s : D i p l . - M a t h . Rolf Nollmann Mathematisches I n s t i t u t der TU MUnchen D-8000 MUnchen 2 Arci sstraI~e 21

S T R U C T U R E D PROGRAMS,

A R C A D I A N MACHINES,

AND THE B U R R O U G H S B1700

W. T. W I L N E R

Abstract S t r u c t u r e d p r o g r a m m i n g has an A c h i l l e s h e e l - - i t s u l t i m a t e d e p e n d e n c e on the u n d e r l y i n g hardware.

W i t h the advent of computers

like the

B u r r o u g h s B1700 w h i c h emulate a r b i t r a r y object code efficiently, w a r e can be freed of its m a c h i n e dependence,

soft-

and the full b e n e f i t s of

structured p r o g r a m m i n g can be realized.

S i m u l t a n e o u s d e s i g n and c o m p o s i t i o n of a p p l i c a t i o n programs, language in w h i c h they are programmed, language's g e n e r a t e d code executes

the

and the m a c h i n e on w h i c h the

is i l l u s t r a t e d by examples drawn

from the B1700.

U n d e r l y i n g tools for s t r u c t u r e d p r o g r a m m i n ~ Software d e v e l o p m e n t

faces an enormous c h a l l e n g e b r o u g h t on by the in-

a d e q u a c y of its p r e s e n t informal methods. p r o j e c t s are to be c o n s t r u c t e d correctly, d i s c i p l i n e d manner.

If large,

complex software

they m u s t be a p p r o a c h e d

in a

One m u s t employ a v a r i e t y of techniques w h i c h re-

duce p r o g r a m size and c o m p l e x i t y to i n t e l l e c t u a l l y m a n a g e a b l e

amounts.

E. W. D i j k s t r a has v e r y e l o q u e n t l y d e s c r i b e d both the m o t i v a t i o n 7 and the m e t h o d s 2 for such structured programming.

One of the p r i n c i p l e techniques

is, as W i r t h describes

it,

"the step-

wise d e c o m p o s i t i o n of the p r o b l e m and the simultaneous d e v e l o p m e n t and r e f i n e m e n t of the p r o g r a m as a gradual p r o g r e s s i o n to greater and greater depth. "16

One begins w i t h an abstract,

and precise,

standing of w h a t b e h a v i o r a p r o g r a m is to exhibit,

under-

and then one pro-

ceeds to make this u n d e r s t a n d i n g more and m o r e concrete.

Dijkstra

gives us a vivid p i c t u r e of w h a t the first few lines of m a i n p r o g r a m code should accomplish: "I w a n t to v i e w the m a i n p r o g r a m as e x e c u t e d by its own, dedicated machine,

e q u i p p e d w i t h the a d e q u a t e i n s t r u c t i o n r e p e r t o i r e

o p e r a t i n g on the a d e q u a t e v a r i a b l e s and sequenced under control of its own i n s t r u c t i o n counter,

in order that my m a i n p r o g r a m

134

would

solve my p r o b l e m

practice, exist,

of course,

so our next

one--is

to p r o g r a m

if I had

this

task--structurally the s i m u l a t i o n

But this bunch of programs probability

will

it in terms

of programs

finally we have Although wrote

Dijkstra

on w h i c h what

was being

ideal machine,

several

(c) a r b i t r a r y matter

these

would

levels

their

structures

ideals,

higher could

to change

at the time he

is similar wanted

itself

to that

a computer

depending

on

could be one's

than c o n t e m p o r a r y with

until

by our hardware." 3

Burroughs

execute

instructions

were. 15

etc.

BI7001

(b) the h a r d w a r e

that in all

be to simulate

machine,

an ideal w h i c h

appear

executed,

ideal m a c h i n e s

how p o w e r f u l

their data

job will

that can be e x e c u t e d

In particular,

m a c h i n e ....

for a m a c h i n e

so our next

he has d e s c r i b e d

(a) the h a r d w a r e

to the o r i g i n a l

'upper'

for a n e x t - l o w e r

a program

designers.

language

is w r i t t e n

not exist,

turn out not to

similar

of the

did not know of the B u r r o u g h s

this passage,

of the m a c h i n e

such a m a c h i n e .... In actual

ideal m a c h i n e will

equal

hardware,

and

efficiency,

no

were nor how s o p h i s t i c a t e d

To the e x t e n t

one can say it was d e s i g n e d

that

the B1700

to support

approaches

structured

pro-

gramming.

One i m p o r t a n t ware"

stractly, note

inference

from D i j k s t r a ' s

no longer n e c e s s a r i l y it means

the lowest

an ideal m a c h i n e

terpreter. known,

refers

which

conceptual

executes

from physical

fits of s t r u c t u r e d

programming

Step-wise

program

composition

the p r o g r a m u l t i m a t e l y words,

fortunate

sense

not be c o n v e n i e n t l y

of d e c o m p o s i t i o n

into an u n f o r t u n a t e

counteract over

the

simply

in terms

of a p r o b l e m

of problems

appear,

hardware

such control

rigidity,

in-

details

are

is that

the major bene-

which

may

because

choice?

the

subroutines

form w h i c h

tool. "17

c l a i m to

their u n d e r s t a n d i n g

suits

the computer?

to have

software

the u n d e r l y i n g

may

decomposition

How can computers contort

attempting

can only be had when

To use

turn out to be un-

of the u n d e r l y i n g

it is i m p o r t a n t

tool" w h e n

can be severe:

machine.

to turn a c o n v e n i e n t

their users m u s t

into a less c o n v e n i e n t

"underlying

will

on the u n d e r l y i n g

can a m a c h i n e

when

it could de-

of the author's

has one d r a w b a c k

How a r r o g a n t

be g e n e r a l - p u r p o s e

"hardab-

of a m i c r o p r o g r a m m e d

implementation

or another

expressed

Hence,

More

be realized.

depends

"the choice

in one

circuits.

no i m p l e m e n t a t i o n

One c o n t e n t i o n

only by l i b e r a t i o n

is that the term

level.

by means

It is the level b e l o w w h i c h

or are significant.

Wirth's

words

to p h y s i c a l

some control

development,

tool

To

and

is not h a r d w a r e

135

as in the past, but something

Ironically,

Dijkstra's

softer.

first p r o g r a m example in r e f e r e n c e

trates a v u l n e r a b i l i t y to h a r d w a r e

idiosyncrasies.

2 illus-

He attempts to

e s t a b l i s h that s u c c e s s i v e e x e c u t i o n of the f o l l o w i n g two statements "dd

:= dd/2;

if d d ~ r

do r := r - dd"

leaves the r e l a t i o n s 0 ~ r < dd invariant. after 100 executions,

K n u t h has o b s e r v e d that

using truncation arithmetic

(as the m o s t common

kind of c o m p u t e r does), dd has been set to zero, due to e x p o n e n t underflow, amples

while r is still positive. 8

Knuth concludes,

"Perhaps ex-

like this will finally be able to convince h a r d w a r e d e s i g n e r s

that it is absurd to d e s t r o y all the s i g n i f i c a n t figures w i t h o u t warning. ''9

Perhaps

just as well,

let the p r o g r a m m e r s

issues are vital become the "hardware"

designers.

to w h o m such

Let them use com-

puters on w h i c h languages are i m p l e m e n t e d by means of u s e r - m o d i f i a b l e microprograms,

so that they can c o n s t r u c t their own u n d e r l y i n g tools

w h i c h behave in proper and p r e d i c t a b l e manners.

Hardware impositions It is i n t e r e s t i n g to c o n t r a s t s t r u c t u r e d p r o g r a m m i n g ' s a c t e r i s t i c s w i t h p r e v i o u s software d e v e l o p m e n t s . m u c h time was spent coding a l g o r i t h m s m i t i g a t e this burden,

top-down char-

Twenty years ago

into b i n a r y or octal forms.

To

F o r t r a n and other early languages b e g a n two

decades of b o t t o m - u p simplifications.

All along, new languages were

u s u a l l y m o s t easily u n d e r s t o o d in terms of w h a t code they g e n e r a t e d on a given computer. coding,

Upon F o r t r a n ' s

s t r u c t u r i n g of a s s e m b l y - l a n g u a g e

Slip added m o d u l e s w h i c h r e d u c e d the effort n e e d e d to do list

processing,

S i m s c r i p t and Gasp s i m p l i f i e d simulation programs,

Formac s i m p l i f i e d formula m a n i p u l a t i o n .

P r o b a b l y the u l t i m a t e

F o r t r a n addenda were the constructs w h i c h made up PL/I. the r e d u c t i o n s

in

Despite all

in the number of lines of code w h i c h m u s t be w r i t t e n

to a c c o m p l i s h a given aim that these various

languages provide,

still sadly true that h a r d w a r e idiosyncrasies,

it is

such as t r u n c a t i o n

arithmetic, m u s t be taken into a c c o u n t w h e n c r e a t i n g programs. over,

and

More-

they m u s t be taken into account as soon as a r i t h m e t i c and other

hardware primitives

appear at a given c o n c e p t u a l level.

So, the sit-

uation is now more complex than 20 years ago b e c a u s e not only m u s t the h a r d w a r e be u n d e r s t o o d but also all the i n t e r m e d i a t e t r a n s f o r m a t i o n s which underlying

software systems enact.

136

Structured p r o g r a m m i n g d e m o n s t r a t e s intellectually manageable

that software tasks can be made

in part by h i e r a r c h i c a l p r o g r a m composition.

Our e x p e r i e n c e teaches that w h e n the grain of things becomes small enough to be bullied by the h a r d w a r e ' s physical c h a r a c t e r i s t i c s , m a n y o t h e r w i s e valid p r o g r a m pieces m u s t be rejected.

It is exactly at

this interface of h a r d w a r e and software that the bulk of p r o g r a m m i n g costs are incurred,

even in s t r u c t u r e d programming.

At one extreme,

there is a s s e m b l y - l a n g u a g e p r o g r a m m i n g w h i c h is always expensive.

At

the other extreme is E. W. D i j k s t r a ' s own code, w h i c h in his w r i t i n g s is o b s e r v e d to go through refinements,

too m a n y of w h i c h appear to be

needed simply to a c c o m m o d a t e hardware.

We m u s t ~ b e g i n to ask, can the

interface between m a n a g e a b l e

software and inflexible h a r d w a r e be

pushed down b e l o w the lowest conceptual cost-incurring,

level?

Can the problem-ridden/

m a c h i n e - d e p e n d e n t details be put off entirely?

F r e e d o m from hardware i1~positions Certainly,

one may achieve m a c h i n e - i n d e p e n d e n t e x e c u t i o n by means of

interpretation.

W h e n programs are not t r a n s l a t e d into d i r e c t l y ex-

ecutable form but instead are i n t e r p r e t e d from some i n t e r m e d i a t e form, then their b e h a v i o r depends more on the interpreter than on the hardware.

To state this more directly,

program behavior

is always depend-

ent on the nature of the computing agent w h i c h e x e c u t e s the program, and this agent may be hard,

firm, soft, or even like w a r m jelly, as in

the case of human beings.

For over seven years, users of the APL language ployed interpreters to run their programs.

ii

have largely em-

They tell us that the phys-

ical h a r d w a r e on w h i c h they are running is p r a c t i c a l l y Consequently,

irrelevant.

the c o n s t r u c t i o n of a large software system in APL is a

task that can avoid "unfortunate choices" of p r o b l e m d e c o m p o s i t i o n because the h a r d w a r e is not allowed to intrude on the p r o g r a m m e r ' s domain. APL users pay a heavy price for such an advantage: Interpretation~

in general,

slow execution.

has been rarely used because it is so slow

c o m p a r e d to e x e c u t i o n of m a c h i n e - l e v e l code.

Until now.

Today there are literally thousands of computers competing

success-

fully in the c o m m e r c i a l e n v i r o n m e n t which interpret programs faster than o r d i n a r y computers can execute them.

M o s t of these m a c h i n e s are

Burroughs Bl700's, on w h i c h system no p r o g r a m s are c o m p i l e d or

137

a s s e m b l e d to m a c h i n e language°

Instead,

each h i g h - l e v e l

language com-

piler g e n e r a t e s code for a fictitious u n d e r l y i n g m a c h i n e whose data formats and i n s t r u c t i o n r e p e r t o i r e are c h o s e n s t r i c t l y for the specific language,

i n d e p e n d e n t of any BI700 h a r d w a r e considerations.

can think of h i g h - l e v e l

language p r o g r a m s as being d i r e c t l y e x e c u t e d

by these fictitious machines,

and in fact each p s e u d o - m a c h i n e

ulated by a separate m i c r o p r o g r a m m e d

interpreter.

ulated m a c h i n e s are called "S-machines",

As a result, hardware,

One

is em-

(On the B1700,

em-

for an arcane reason.)

all BI700 programs are i n d e p e n d e n t of the u n d e r l y i n g

and behave in the same way on any other piece of h a r d w a r e

w h i c h also emulates a p r o g r a m ' s

S-machine.

One m i g h t observe that

this is so d e s i r a b l e a p r o p e r t y that the w o r l d ' s largest computer manufacturer

(in 1973, I.B.M.)

in a r e s t r i c t e d sense. common p s e u d o m a c h i n e ,

committed

itself to a c h i e v i n g this end

Each model of the System/360

line emulates a

namely the System/360, while the nature of the

h a r d w a r e and the c o r r e s p o n d i n g

i n t e r p r e t e r differs from m o d e l to m o d e l

The i m p o r t a n t d i s t i n c t i o n b e t w e e n the B u r r o u g h s and IBM a p p r o a c h is that the B1700 was d e s i g n e d for an o p e n - e n d e d

set of S-machines, w h e r e

as the 360 tries to get by with just one S-machine

(or just two,

c o u n t i n g the 1401 emulator).

One w o u l d expect the p e r f o r m a n c e of i n t e r p r e t i n g computers to vary m a r k e d l y d e p e n d i n g on their h a r d w a r e characteristics.

From the

Univac I up to the present, m a c h i n e h a r d w a r e has been w r o n g for interpretation, b e c a u s e that was never the objective. the B1700 and m a c h i n e s

W i t h the advent of

like it, there is no longer a p e r f o r m a n c e dis-

a d v a n t a g e for interpretation,

and software is now free to be imple-

m e n t e d with that in mind.

An____aside on securit [ We m i g h t observe in passing that p s e u d o m a c h i n e s cure systems than c o n v e n t i o n a l a r c h i t e c t u r e can.

can provide more seTo obtain security,

it is n e c e s s a r y to e s t a b l i s h clearance p r o c e d u r e s and to e l i m i n a t e ways of thwarting those procedures.

W h e n s e c u r i t y p r o g r a m s run on the

h a r d w a r e while user programs do not, m a n y sound v e r i f i c a t i o n s of security are available. procedures

The data a c c e s s i n g m e c h a n i s m s

simply do not reside in the user's domain.

are a part of the i n t e r p r e t a t i o n process,

and a u t h o r i z i n g Instead,

they

that is, at a s y s t e m level

to which the user cannot p e n e t r a t e w i t h o u t elaborate d e c e p t i o n s that m u s t pass a v a r i e t y of c o n v e n i e n t checkpoints.

Even so p r i m i t i v e an

138 action as accessing m e m o r y or as e x e c u t i n g an i n s t r u c t i o n can take place only w i t h the i n t e r p r e t e r ' s consent; nothing for himself directly.

the user really can do

F r e e i n g the user from h a r d w a r e ' s

impo-

sitions has the d e s i r a b l e side effect of subjecting him to another's control.

In the same vein, p r o t e c t i o n preting computers.

is likewise easy and thorough on inter-

Once one begins to pay the cost of interpretation,

the added cost of, for example, d y n a m i c a l l y c h e c k i n g s u b s c r i p t values during array references

is insignificant.

Protection mechanisms

w h i c h are so hard to impose on c o n v e n t i o n a l m a c h i n e s are much easier on m a c h i n e s d e s i g n e d for interpretation.

Arcadian machines Given that p r o g r a m m i n g

languages are to be i m p l e m e n t e d by means of

soft u n d e r l y i n g tools,

several s p e c u l a t i o n s are in order.

(i) The

range of a r c h i t e c t u r e s which can be e f f i c i e n t l y i n t e r p r e t e d is m u c h larger than the range of extant architectures. are based on a given p r o g r a m m i n g t e m p o r a r y machines.

(2) S-machines w h i c h

language are m u c h simpler than con-

(3) W h e n a language and its u n d e r l y i n g m a c h i n e

are d e s i g n e d simultaneouslyr

both the language and m a c h i n e become

elegant and m o r e e f f i c i e n t than c u r r e n t languages and machines.

(4)

D e v e l o p i n g an a p p l i c a t i o n by s i m u l t a n e o u s l y c o m p o s i n g its program, p r o g r a m m i n g language,

the

and the u n d e r l y i n g m a c h i n e leads to solutions

w h i c h are superior to those w h i c h are d e v e l o p e d when any of the three constituents

is fixed.

(This is similar to the o b s e r v a t i o n s r e p o r t e d

in c o n j u n c t i o n with T.H.E. m u l t i p r o g r a m m i n g system 6 and Project SUEI~) These speculations are d e r i v e d both from p h i l o s o p h i c a l c o n s i d e r a t i o n s and from e m p i r i c a l evidence. To d e v e l o p an o p e r a t i n g system for the BIT00, we began w i t h an understanding of p r e v i o u s Burroughs' new p r o g r a m m i n g language

signed an S-machine for SDL. (Incidentally,

created a

This gave us a first approximation.

the first S-machine was e m u l a t e d on a B5500, m o n t h s be-

fore the first B1700 was built. a B1700,

M a s t e r Control Programs,

(SDL) in w h i c h to code it, and lastly de-

W h e n the BI700 MCP was t r a n s f e r r e d to

it n a t u r a l l y w o r k e d the first time.)

three parts is continuing,

D e v e l o p m e n t of all

as new functions are added and p e r f o r m a n c e

improvements are incorporated.

F r o m this c o n s t a n t d e v e l o p m e n t and

c o n c o m i t a n t w o r k on the B1700 compilers, we are learning things about simultaneous design and c o m p o s i t i o n of the application,

language,

and

139

machine°

Simpliqity The B1700

in the SDL S - m a c h i n e MCP

the initial

is our m o s t

objectives,

structured

It follows

that the SDL m a c h i n e

After

why put a b r a n c h

it?

all,

The SDL m a c h i n e

such as Call ponding

the control ... then

...;

2.

if

... then

...;

3.

case

4.

do A;

5.

do A forever;

6.

procedure

A;

7.

procedure

A

forms

...;

...;

...;

...; ...;

the

"if

of the usual the SDL

instruction. is no use

control

language

for

operators,

has corres-

stream

by the

structural

undo A;

.o.;

all

end A;

end A;

return

...;

but m o s t

...; end A;

readers

is e x e c u t e d

having

branch

however,

branch

instruction

at a given

preceding

are alien.

which

is stopped

all h i g h e r m a c h i n e s

as a

the of lin-

What

structure

is

as the

to indicate

is executing°

are c o m p l e t e l y

machine.

visualized

the notions

the same

a machine

level

understand

by a p a r t i c u l a r

a stack of pointers

to e x p l a i n

lower m a c h i n e s

probably

is t y p i c a l l y

a conditional

is code h a v i n g

level w h i c h

"If a m a c h i n e

while

that

...;

...;

and c o n d i t i o n a l

language

cite D i j k s t r a

instruction,

end case;

the SDL language,

text and a m a c h i n e

can again

...;

stream with

instruction

suggested

in SDL include:

... then ~' c o n s t r u c t

Given

placed,

there

...; end A;

exit;

...;

code.

isted~

a branch

when

goto.

...;

should be familiar,

instruction

statement

else

...; undo A;

them in terms of the code

each

constructs

if

source

not have

one of

a single

constructs.

For example,

ear

that b e i n g

not c o n t a i n

into a m a c h i n e

but only b e c a u s e

i.

linear

does

does

has a c o m p l e m e n t

and Exit,

Specifically,

These

s y s t e m program,

and n a t u r a l l y

In fact,

for we

he did not know exbetween

passive

m u s t be r e g a r d e d

two of its

and can be re-

as engaged

in the

m i d d l e of an instruction: their state m u s t be c o n s i d e r e d as being in transition. ,,4 (N.B.: In this p a r t i c u l a r case, D i j k s t r a is r e f e r r i n g to m a c h i n e s only

which

are d i f f e r e n t

the i n s t r u c t i o n

level.) ing form.

Conditional

counter

which

statements,

The c o n d i t i o n a l

at each

expression

If the c o n d i t i o n to a l l o w the

the c o n d i t i o n a l

statement.

When

is true,

for SDL it is

separately

compile

is r e g a r d e d

suspended

level

while

is m a i n t a i n e d

therefore,

the k th level machine. at that

level,

as being

follow-

computed

then p r o c e s s i n g

(k+l) th level m a c h i n e

it is done,

for each

into the

control

by

is

to e x e c u t e

returns

to the

140

k th level m a c h i n e trate,

at a point

following

the if statement.

To illus-

the two statements "if A then B else C; D"

become

three d i s j o i n t

pieces

of code:

A*

B*

C*

IFEL,@B*,@C*

UNDO

UNDO

D* where

"X*" means

the code compiled

been evaluated,

the result

either

the code

for B or for C.

pushed

into

the IFEL.

a stack, After

saving

the p r o g r a m p o i n t e r

Note

that

guage

is.

This

Furthermore, are invoked

procedure

their m a n i p u l a t i o n

In addition, selection

case

bits

statements

the same

What does underlying

this

the same

pointer

machines.

can be imagined.

That

and scope

IFTH,

IFEL,

engines

begins

of code

the if s t a t e m e n t case.

corresponding

SDL programs

(except

to

using and ob-

for the opcode that the

and that the p r o g r a m p o i n t e r

same which

which

but

dynamically.

design?

at the

mechanisms

Hardware

is,

case

and CASE operators),

set of v a l u e s

rules,

is identical.

code execution,

generated

They

manipulates

is a t w o - e l e m e n t

for c o n d i t i o n a l code was

are created

to d i s c o v e r

pect to invent c o m p u t i n g temporary

stack

in fact, write

tell us about m a c h i n e

machine

we can expect

is m e a n t by the

simultaneously

local v a r i a b l e s

ran in the same amount of time~

stack c o n t a i n e d

just as the lan-

of w h a t

by n code addresses,

One could,

to the

simply

by the same m e c h a n i s m .

which

and the i f - t h e n - e l s e

exclusively

corresponding

is following

to D.

are seen to be the general

is followed

that exactly

program

instance

than two alternatives.

the n case elements.

serve

operator

statements

The CASE o p e r a t o r

control

recursive,

calls are h a n d l e d

to do w i t h

case,

pointer

design".

of the p r o g r a m

for m o r e

is a o n e - e l e m e n t

case

is i n h e r e n t l y

by a d i f f e r e n t

the stacks w h i c h have

program

A has

to select

of the i n s t r u c t i o n

returning

is a good

"language-directed

the e x p r e s s i o n

of B or C, the U N D O o p e r a t o r

stack,

such a m e c h a n i s m

construct

phrase

After

IFEL o p e r a t o r

The current

the location

the e x e c u t i o n

pops

for X.

is used by the

When

a language

and its

time by the same person, simplify

are m u c h

to support

both.

We can ex-

less ad hoc than conlanguages

In the case of SDL control m e c h a n i s m s ,

as well we have

as ob-

141

tained

an S - m a c h i n e

We should cribing

complete

which

the d i s c u s s i o n

the i m p l e m e n t a t i o n

can see that compile

simple,

or arcadian.

of the SDL control

of the i t e r a c t i v e

it is p o s s i b l e

to r e m a i n

mechanism

construct

by des-

do forever.

true to the stack c o n c e p t

One

and

the two s t a t e m e n t s "do forever;

into

is i d y l l i c a l l y

S;

if T then undo;

U; end;

V;"

two parts: S W

CALL,@S*

T*

V*

UNDC U* CYCLE,@S* where

the CYCLE

iately pushes

operator

the address

the UNDC o p e r a t o r result date

pops

the p r o g r a m

of the iterate

is a c o n d i t i o n a l l y

of c o m p u t i n g

T.)

However,

the top of the p r o g r a m

which

has

ments

the i n s t r u c t i o n

by w h a t e v e r

amount

is as close

as the SDL m a c h i n e

but

its a n c e s t r y

special rather ister.

is r e a l l y

One final word:

Knuth w i s h e s

he had. I0 which

pointer

entries

stack

the o u t e r m o s t

example,

notion

CYCLE

callin

do B;

... ...

easily

nested

implements

they had calls

a

language,

address

reg-

group w h i c h

the improved

in Bliss, 18 and w h i c h

the n u m b e r

is clear

of p r o g r a m

from the source

if the p r o g r a m m e r

he w i s h e s

;

; ...;

if D then undo A;

end B;

This

instruction,

can be e x i t e d by a single

that holds

by a c o m p i l e r

do forever;

end;

for S.

a goto-less

the SDL e x c e r p t "do A forever;

stack,

from s i m p l i f y i n g

of an i n s t r u c t i o n

The n u m b e r

computed

to upfunction

in common.

an a r g u m e n t

to pop.

on the

simply d e c r e pointer

a branch

It derives

et al. w i s h

"do...end"

is a simpler

at the code

to h a v i n g

procedure

Several

has

text and can be e a s i l y named

comes

the UNDO m e c h a n i s m

UNDO o p e r a t o r

(Incidentally,

depending

the top of the p r o g r a m

nothing

f u n c t i o n w h i c h Wulf

on.

UNDO,

there

to again p o i n t

from the h a r d w a r e

There

stack,

different.

case of a r e c u r s i v e than

escape

is n e e d e d

is v a s t l y

code back

executed

In the SDL machine,

counter,

stack and immed-

as long as we are just going

pointer

the same effect.

pointer

..o

;

to leave.

has For

142

end A;" will result in an UNDC,3 operator being c o m p i l e d to a c c o m p l i s h the "undo A" request.

Each UNDO and UNDC o p e r a t o r has a four-bit argu-

m e n t w h i c h indicates how many nested levels to exit, usual case of one level. m e n t to three bits,

(There is a move afoot to reduce the argu-

for the two good reasons that

uses the fourth bit, and

even for the

(a) no one ever

(b) anyone who nests more than seven levels

w i t h o u t a procedure call d o e s n ' t know w h a t he is doing.)

Steps toward arcadian m a c h i n e s It is i m p o r t a n t to record that this "do, undo, end" c o n s t r u c t was not initially c o n c e i v e d in so simple a form.

It evolved to this flexible

and fast device because of our d e s i r e to make the source code concise and the object code speedy,

abetted by o c c a s i o n a l

the language was being used and by complete

insights about how

freedom to change the

"hardware".

It is the ease with w h i c h a language and m a c h i n e d e s i g n e r can delete or insert bits into his object code formats, replace an i n s t r u c t i o n address register w i t h a stack, and add tag bits to his data,

that

makes it p l a u s i b l e that the B1700 will enable us to s i g n i f i c a n t l y improve our u n d e r s t a n d i n g of p r o g r a m m i n g languages.

Twenty years

of b o t t o m - u p s i m p l i f i c a t i o n s have not p r e v e n t e d the p r e s e n t software crisis.

I think it is safe to say that none of those s i m p l i f i c a t i o n s

were based on a formal c h a r a c t e r i z a t i o n of w h a t was taking place at the lower

(machine)

level°

W h e n the machine

level functions are form-

alized, m a n y problems of software c o n s t r u c t i o n are reduced. APL is not formally defined,

Although

the language itself is so m a t h e m a t i c a l

that m a n y p r o g r a m properties can be u n d e r s t o o d w i t h o u t knowing the implementation.

One promise of i n t e r p r e t i n g computers

is that form-

ally u n d e r s t o o d i m p l e m e n t a t i o n s can be obtained, w i t h o u t s a c r i f i c i n g performance.

Then real p r o g r e s s in software d e v e l o p m e n t can be made.

A p r i m e example It w o u l d break a short tradition to discuss structured p r o g r a m m i n g w i t h o u t including a prime number g e n e r a t i n g program. are like the e x p e r i m e n t a l psychologists' w h i c h g u a r a n t e e s u n i v e r s a l applicability.

white rats,

Prime numbers the in vivo trial

In previous cases,

an

author's p r o g r a m reaches a certain level of r e f i n e m e n t w h i c h seems a g r e e a b l e to humans and which could be p r e c i s e l y defined.

Yet,

several more refinements are n e c e s s a r y before the p r o g r a m is accept-

143

able to a s o - c a l l e d h i g h - l e v e l

language compiler.

Our point here will

be to stop the r e f i n e m e n t s as soon as is practical, tively)

knowing

(intui-

that we can devise a c o m p i l e r and S-machine on the BI700 which

w i l l w o r k as e f f i c i e n t l y as the c o n t e m p o r a r y m a c h i n e r y w h i c h u n d e r l i e s the lower h i g h - l e v e l language.

Let us begin at the usual starting point.

A p r o g r a m to print the

first thousand prime numbers m i g h t read b e g i n "print first t h o u s a n d prime numbers" end and, as D i j k s t r a points out, that w o u l d be all. microprogrammable

if one's c o m p u t e r had such an i n s t r u c t i o ~

Indeed there is n o t h i n g p r e v e n t i n g any user of a c o m p u t e r from o b t a i n i n g such an instruction,

than common sense.

In the first place,

other

the i n s t r u c t i o n w o u l d never be

e x e c u t e d often enough to justify the effort.

Secondly,

to do so would

only transfer the p r o g r a m m i n g b u r d e n from the h i g h - l e v e l language to the m i c r o c o d e realm, where

far less a g r e e a b l e tools are used.

The

real o b j e c t i v e is to incorporate the semantics of a l g o r i t h m s at whatever level, hard, ting cost.

firm,

soft, or jelly, will m i n i m i z e the total compu-

This c r i t e r i o n may well show that D i j k s t r a ' s solution is

optimum: 1

integer array p

2

begin integer k, j;

3

[i:i000];

integer ord;

4

integer square;

5

p

6

b e g i n ord

7

while k
8 9 i0 Ii

[i]

integer array m u l t

[1:30];

:= 2; k := i; j := i; := i; square

:= 4 end;

do

begin begin b o o l e a n

jprime;

r e p e a t j := j + 2; begin

12

while

13

( s q u a r e ~ j) do

begin m u l t

14

ord

15

square

16

[ord]

:= square;

:= ord + i; := p

[ord] # 2;

end

17

end;

18

b e g i n integer n; n := 2; jprime

19 20 21

while n
and jprime do

begin begin integer r;

:= true;

144

22

begin

23

while m u l t

24

mult

25

r

26

:= m u l t

:= j - m u l t

[n] + p

[n]

[n]

end;

27

jprime

28

:=

(r ~ 0)

end;

29

n

30

:= n + 1

end

31

end

32

until

33

end;

34

k

35

jprime

:= k + i; p

[k]

:= j

end

36

end;

37

print p

Without

[k] for k from 1 through

suitable

fact g e n e r a t e

comments,

p r o g r a m does. Dijkstra

integer

2

begin

3 4

to observe

array p

begin

5

"increase

in

numbers.

an i n t e r m e d i a t e

form of the

and the final program, 5 code is, loosely:

that his

[1:1000];

"table p not

code does

the o n e - l i n e r

"set table p and

while

to see that this

it is easy to see w h a t

In b e t w e e n

pauses

1

i000;

it is hard

the first 1000 prime

On the other hand,

integer

j;

j at initial

full" j until

value";

do next prime

number

to be added";

"add j to table p"

6

end

7

end;

8

print p

[k] for k from

This would be a very nice yield

to the m a c h i n e

can define a table, That

[n]

[ n ] < j do

structure

it a t t r i b u t e s

is, one can define

structures, perties

followed

"object.attribute". to c o n f o r m modating

tables

or procedures,

of a table.

an object,

stopping

any further.

a new data

and give

1 through

These

point, Using

which of

corresponds

and a s s o c i a t e

like Simula,

to one's

value", with

"full"

represent,

attributes

can then be a c c e s s e d

current

identifier,

(although

are fully d e v e l o p e d

notion and

or calculate,

of

"add".

pro-

by n a m i n g

in the form

the i n t e r m e d i a t e

syntax

one

them other data

w h i c h help

Let us rewrite

syntax

so let us see h o w not to a language

"initial

by the a t t r i b u t e ' s

to Simula's

the richer

1000;

program

techniques in Mlisp213

slightly

for accomand its

145

successor

Lisp7014).

one can m a k e palatable means

form.

"X

:= Y

be added",

"Y.add

external

class (j);

ref

2

begin

3

(table)

4

table p; counter

increase

end;

8

print p

X until

"next p r i m e

change.

Further,

procedure

j; table p j.initial

Y"

number

take

to

"add X

next prime

:- new table

number

to

(i000) ;

value;

do

j until

next prime

number

to be added;

p

[k] for k from 1 through

Since D i j k s t r a cussion

doesn't

of this

to him and was

code,

there

To create

a Simula

an initial

class,

2

begin

3

(n);

integer

4

integer

k;

5

procedure

6

begin

7

procedure

8

begin

initial

p

begin p

10

end

11

for an integer

[k]

declarations.

array w i t h

for adding

full w h i c h

attributes

an entry

indicates

at

that

the

[l:n];

k

:= 1 end;

(x) ; integer

if not full

9

the e x t e r n a l

vaiue;

:= empty; add

obvious

n;

array p

full;

was

one may write

integer

boolean

after his dis-

this r e n d e r i n g

a procedure

and a b o o l e a n

filled,

until

grounds.

to s p e c i f y i n g

table,

position,

table

that

on p e d a g o g i c a l

value procedure,

last slot has been

1000;

subroutines

we can assume

is no trick

the next u n u s e d

class

introduce

shunned

Certainly

12

"increase

end

7

1

value;

that

Algol,

into more

us:

(n); e x t e r n a l

add j to table

6

of:

table

not table p . f u l l

begin

5

4 without

Extended

some syntax

a procedure

This gives

table p . i n i t i a l

while

by d e c l a r i n g

line

(X)"

like B u r r o u g h s

to render

and by d e c l a r i n g

we can r e t a i n

be added 1

a language

substitutions

For example~

(X)",

to Y" to m e a n 0

Using

symbolic

x;

then

:= x; k

:= k + I; full

:=

(k~n)

end add; end table;

(Strictly

speaking,

the array

but an A P L or PL/I o p e r a t i o n code thing

leaves

open

to a full

the q u e s t i o n table.)

assignment

in line

shouldn't

frighten

of w h a t

to do w h e n

Further

clarification

6 is not in Simula, anyone. asked

Also,

this

to add some-

of Simula

constructs

146

can be found in Dahl's portion of r e f e r e n c e 2.

Next,

to declare the prime number procedure,

i l l u s t r a t e d in D i j k s t r a ' s program,

using the technique

one may assemble a v a r i e t y of syn-

tax from m a t h e m a t i c s which has been s u c c e s s f u l l y t r a n s f e r r e d to prog r a m m i n g in several l i t t l e - k n o w n languages, 1 2

and obtain

integer p r o c e d u r e next prime number to be added

(j); integer j;

do forever;

3

bump j by I;

4

if for all x such that x ~ table p A x < q ~ ,

j mod x ~ 0

then return j 5 6

end end;

If one is d e s i g n i n g a language to do mathematics,

one s h o u l d n ' t

h e s i t a t e to ask the c o m p i l e r to help w h e r e v e r it can. i n t e r p r e t i v e machine,

W h e n one has an

he does not have nearly as m a n y l i m i t a t i o n s on

language operators and data structures as with a c o n v e n t i o n a l c o m p u t e n

At this point our p r o g r a m is not as refined as possible. added the s o p h i s t i c a t i o n of only e x a m i n i n g odd numbers, However,

We h a v e n ' t for example.

the real q u e s t i o n is, has it been p r o g r a m m e d in such a way

as to exhibit m a n a g e a b l e parts? Dijkstra's code,

Since we h a v e n ' t d e v i a t e d from

the answer must be yes.

argued that a readable,

concise,

All we have really done is

and c o n v e n i e n t form of the code can

also be the lowest level~ suitable for m a c h i n e execution. already exist compilers w h i c h can handle

There

such a form; all that is

needed in a d d i t i o n is a convivial u n d e r l y i n g mechanism,

and we claim

that the B1700 suffices.

C o n c l u d i n g remarks One of the purposes of this h a r a n g u e is to suggest that there are many aspects of programs w h i c h can now e f f e c t i v e l y stay b e l o w the source code level, even w h e n e f f i c i e n c y is being considered.

For example,

it

is i r r e l e v a n t w h e t h e r or not the table in our example is filled by inc r e a s i n g or d e c r e a s i n g a subscript. last, and next is available, way that suits the machine;

As long as a c o n c e p t of first,

the internal o r d e r i n g can be done in any it does not have to be imposed from the

outside. A n o t h e r s u g g e s t i o n is that w h e n one d e v e l o p s a p r o g r a m m i n g

language

from the s t a n d p o i n t of the a p p l i c a t i o n rather than b o t t o m - u p from the

147

hardware, one begins to use much more powerful data types than those suggested by the memory implementation.

One also uses more abstract

operators, which perform their function according to data-dependent attributes, rather than according to processor architecture.

At all times, the objective is to obtain the cost-wise optimum decomposition of a computing task into hard, firm, and soft mechanisms. Any program which is to be run once need only be correct; forget about speed.

Any program which requires less than a man year of develop-

ment, probably doesn't require simultaneous language development.

Any

computational task which will consume less than 10% of an installation's time probably doesn't require simultaneous firmware development.

Any computing which will be done by less than 20% of a given

machine's population probably doesn't need hardware development.

For

those computing tasks, however, which are so prevalent that language, firmware, or hardware support is advantageous, it is vital to have a computing engine which is pliable.

People will change what is

changable, in order to improve their situation.

When the underlying

tools are inflexible and rigid, people are forced to change the way they understand a problem's solution.

When they can exercise some

control over the underlying tools, as on the BI700, they can retain what is good about any particular understanding of a problem's solution and change the "hardware" to suit that understanding. References !.

Burroughs BI700 Systems Reference Manual, Form 1057155, Burroughs Corporation, Detroit

2.

(1972).

Dahl, O.-J., EoW. Dijkstra, and C.A.R. Hoare, Structured Programming, Academic Press, London

3.

(1972).

----, 48-49.

4.

----, 49.

5.

----, 33.

6.

Dijkstra, E.W., The structure of the T.H.E. multiprogramming system, CACM ii

7.

Dijkstra, E.W., The Humble Programmer ture), CACM 15

8.

(1968), 341-346. (1972 ACM Turing Award Lec-

(1972), 859-866.

Knuth, D.E., A Review of " S t r u c t u r e d Programming", STAN-CS-73-37!f Computer Science Department, Stanford University, Stanford, California

9.

----,I.

i0. ----, 6.

(1973), i.

148

ii. Pakin,

S., APL/360

Inc., Chicago, 12. Sevcik,

Reference Manual,

Illinois

Science Research Associates,

(1968).

K.C., et al., Project SUE as a learning experience,

Proc.

FJCC 41 (1972), 331-338. 13. Smith, D.C., MLISP,

STAN-CS-70-179,

Stanford University,

Stanford,

Computer

California

Science Department,

(1970).

14. Smith, D.C., private communications. 15. Wilner, W.T.,

Design of the Burroughs

B1700,

Proc. FJCC 41 (1972),

489-497. 16. Wirth,

N., Systematic

Programming:

Inc., Englewood Cliffs,

New Jersey

An Introduction,

Prentice-Hall,

(1973) r 126.

17. ----, 126. 18. Wulf, W.A., D.B. Russell, for Systems Programming, Dr. Wayne T. Wilner, Burroughs 93017.

Manager,

Corporation,

and A.N. Habermann,

Bliss: A Language

CACM i~4 (1971), 780-790. Systems Technology

6300 Hollister Avenue,

Department,

Goleta,

California,

USA,

STRUKTUREINHEITEN

IN KONTEXTFREIEN

SPRACHEN UND !HRE OBERSETZUNG

W. NIEGEL

I. Einleitun 5 Aufgrund der beachtlichen Zahl verschiedenartiger finition yon Programmiersprachen,

Methoden zur De-

die in den vergangenen Jahren vor-

gelegt worden sind und im Hinblick auf ihren Verwendungszweck

erhebt

sich an jede weitere Arbeit auf diesem Gebiet die Grundforderung: Eine Programmiersprache

mu~ weitgehend

formal beschrieben werden.

Dieser Forderung soll im fo!genden dadurch Rechnung getragen werden, da5 zu gewissen noch zu pr~zisierenden definiert werden,

'Struktureinheiten'

Obersetzungen

mit deren Hilfe einer durch eine Struktureinheit

festgelegten Zeichenreihe

eine zweite Zeichenreihe

'ihre Bedeutung'

zugeordnet werden kann. Wir gehen davon aus, da~ die Syntax der zu betrachtenden

Programmier-

sprache L durch eine Grammatik gegeben ist und beschr~nken uns auf Grammatiken,

deren Produktionen

kontextfrei

sind; es kann sich also z.B.

um eine kontextfreie Grammatik oder eine van-Wijngaarden-Grammatik handeln.

Bezdglich der Syntax stellt sich dann nur noch die Frage,

die Grammatik in eine Form zu bringen,

die m~glichst

geeignet

ist fur

die spezielle Art der Zuordnung einer Bedeutung zu einem syntaktisch richtigen Programm.

Die Forderung betrifft damit allein die Beschrei-

bung der Semantik der Programmiersprache

L.

Da wir eine operative Beschre±bung der Semantik anstreben, heist das: Die Bedeutung eines Programms oder eines Ausschnitts aus einem Programm aus L soll durch eine zweite Sprache,

eine semantische

Sprache~

ausgedr~ckt werden. F~r die Beschreibung der Semantik der Sprache L wird nun die Forderung erhoben: Die Definitionsmethode von ihm bzgl.

des Strukturbaums als

sol/. dem Sprachdesigner

erm6glichen,

der Bedeutung als atomar betrachteten

g a n z e m

einem

Segment A

eines syntaktisch richtigen Programms aus L eine Bedeutung b (a) zuzuordnen.

Ein solches

150

Segment

A wird als Struktureinheit

Wenn sich eine Struktureinheit

(des Strukturbaums)

A aus Unterstrukturen

so soll die Bedeutung dieser Unterstrukturen Bedeutung b (A) der Struktureinheit wichtig,

bezeichnet.

zusammensetzt,

ohne Belang for die

A sein; es ist dann sogar un-

ob f~r diese Unterstrukturen

~berhaupt

eine Bedeutung de-

finiert wird~ Struktureinheiten spezifiziert

eines Strukturbaums

werden.

derung erf~llt,

wenn jeder Produktion

Zur Beschreibung Hilfsmittel

der Zuordnung

erforderlich.

eine Bedeutung

Da im allgemeinen

wird zu ihrer Beschreibung

zugeordnet

wird.

der L[nge g r ~ e r

ein Relationensystem '~bersetzt'

a!s

benS-

wird, das seine

darstellt.

Ein Grund f~r die Einf~hrung einheiten

die For-

jedoch auch Strukturein-

die Ableitungen

tigt, das in ein zweites Relationensystem 'Bedeutung'

der L[nge I i s t

sind in diesem Fall keine besonderen

heiten zugelassen werden sollen, I entsprechen,

k~nnen z.B. durch Ableitungen

Im Fall einer Ableitung

der als ganze interpretierten

Struktur-

kann z.B. sein, dab man gewisse in der Programmiersprache

realisierte

s p r a c h I i c h e

als Einheiten

behandeln

licher Einheit entsprechende konsequent ausgesetzt,

auch in der Semantik

F~hrt man diese Zuordnung

(Grundkonzepte ,der Programmiersprache) Struktureinheit

dutch,

Grundkonzepte

mSchte.

Einheiten

zur Bedeutung

dieser Struktureinheit

so wird sich bei geeigneter

die Syntax und Semantik

Wahl der sprachlichen

~bersichtlicher

dab der hierf~r einzusetzende

yon sprach-

~ber die ihr

Apparat

gestalten,

gen~gend

vor-

einfach

ist. Auf diese Weise k6nnten segar die beim Benutzer

der Sprache mit

den sprachlichen

der formal de-

Konzepten

verbundenen

Vorstellungen

finierten Bedeutung wesentlich

n[her kommen~

terteilung der Struktureinheit

mSglich ist. Der Benutzer

grammiersprache gramm,

schreibt

n[mlich nur in den seltensten

in dem er explizit

Bedeutung

zur~ckgreift.

ebene gar nicht,

als das bei weiterer

F[llen ein Pro-

auf die Regeln oder Produktionen

und deren

In den meisten F[llen kennt er diese Sprach-

da er nut an der Ebene interessiert

gewisse sprachliche

Un-

einer Pro-

Konzep~ und die Spielregeln

denen er aus einfacheren

kompliziertere

Konzepte

ist, in der ihm

angeboten werden, und schlieSlich

mit ein

ganzes Programm aufbauen kann. Am besten veranschaulicht

zun[chst

einheit'

eines Strukturbaums.

fikator'

und

'Indexliste'

ein Belspiel

Betrachtet

als sprachliche

den Begriff

man hierin Einheiten,

'Struktur-

'Variable',

'Identi-

so k6nnen die

151

beiden in Figur la und Ib dargestellten Segmente als Struktureinheiten angesehen werden. variable>

>



i

l simple variable

idenlifier>

Figur la

Figur ib

Zwei Segmente aus dem Strukturbaum eines ALGOL 60-Programms[2] In die Bedeutung der Struktureinheit St () yon Figur la geht die Bedeutung yon St () ein; in Figur lb geht die Bedeutung yon St () und St (<subscript list>) ein. Die beiden Struktureinheiten stehen f0r sechs ALGOL 60-Regeln. Wie schon an diesem einfachen Beispiel zu sehen ist, mu5 bei der vollst~ndigen Behandlung des Problems zu jeder metalinguistischen Variablen eine ganze Klasse yon Struktureinheiten berdcksichtigt und interpretiert werden; denn erst dadurch werden die Alternativen auf den rechten Seiten der Regeln ber~cksichtigt. Um die Hilfsmittel fdr das bisher skizzierte Konzept zur Verfdgung zu stellen, werden Begriffe eingefNhrt, die in gewissem Zusammenhang mit der syntaxorientierten 0bersetzung yon A h o u n d

Ullmann

[i]

Die beiden Autoren definieren ein 0bersetzungsschema T : ~ In ibm ist N eine Menge yon nichtterminalen Zeichen, s Eingabealphabet und ~ ein Ausgabealphabet. definiert durch {a ÷ ~, ~ I a ¢

N ^

~

~

(NO~)*A~

stehen.

(N,Z,A,R,s). ~

N, ~ ein

Die Menge R der Regeln ist

¢ (Nua~}.

Die Anwendung einer Regel aus R bedeutet die simu!tane Ersetzung eines nichtterminalen Zeichens a in einer Zeichenreihe z ¢ ( N U E ) *

und des

stets vorhandenen und ihm assozilerten Zeichens a in der zu z korrespondierenden Zeichenreihe ~ ~ (NU A)'. Auf diese Weise werden Paare yon Ableitungen eines 0bersetzungsschemas ~ s o w i e

die Obersetzung von

Strukturb~umen und ihrer terminalen Zeichenreihen definiert.

152

2. Definitionen und Bezeichnunsen Sei Q :~ (N, T, R, s) eine kontextfreie Grammatik mit der Menge N der nichtterminalen Zeichen, der Menge T der terminalen Zeichen, mit der Regelmenge R C N × ( N U T ) che und

~ und s ~ N. Sei L (G) die von G erzeugte Spra-

~ ein Element aus L (G). Kann einem z genau ein Element

b (~) aus einer noch n~her zu spezifizierenden Menge B :~ {x I x £ A~^~ A b ist Alphabet} zugeordnet werden, so ist L

(G,

eine

b

beten

(~)

, b

sind

T bzw.

(~))I

L

M i,

(G)Ab

Sprache' nach

mit

(~)eB} kontextfreler

Voraussetzung

bedeutungstragenden

Hilfsmittel,

die

formuliert, Folgende

einer

der (G)

also

~ ~ L

Grammatik

Zeichenreihen

Uber

G. den

Alpha-

A b.

Semantik

samtheit ~

:~{(~

'bedeutungstragende

und

Die

B)

zugeh~rige

um

~ in das

weiteren i~- i~_~,

die

benStigt

Bedeutung eindeutig

L um

(~) ~

bestimmte

Bezeichnungen endliche

b

Sprache werden,

werden

noch

(G,

B)

B zu berechnen b

(~)

umfa6t

zu einem

die

Ge-

gegebenen oder,

anders

zu Ubersetzen.

ben6tigt:

Mengen.

Re!ationen zwischen M i und Mj: p~ C_ M i x M j

fur 1 -~ i , j - ~

und I -~ r ~- rij. ~

!m Fall i : j steht zur Vereinfachung p[ fHr ~i~und P P[~.....~ : ~ U o[~

mit 1~- r ~ - ~

Eine p ~ ....... ~-Kette :~

*{ f~r ~{.

f~r 1~-i~- p.

K f ~.......*~ (m, n) yon m e M i nach n e M i

eine lineare Folge {~}[~9~ yon Elementen aus Mi, die folgende Bedingungen erfUllen: 1. m~ : r~und m9 : n. 2.

(m~,

m¢~ 4 )ep~ ~ ....~fUr

1 ~-~-~ q - 1.

3. Das Z-Gebilde 3.1. Definition und Eigenschaften Es soll nun der Begriff eingefUhrt werden, der fur die Pr~zisierung der

'Strukturelnheit'

und der

'Bedeutung einer Struktureinheit'

be-

n~tigt wird. Beide sind im allgemeinen Untergebilde eines die ganze zugrundeliegende Grammatik repr~sentierenden Relationengebildes.

153

Def. I Ein Z-Gebilde ist ein Siebentupel

(M, ~

, p2,

~

~,

p

, f,

t)

f~r das gilt: a) Das Relationengebilde

(M, pl , p2 , p~, p~ ) besitzt die durch

das Axiomensystem~festgelegten b) f : Feld ( p l Z ~ )

Eigensehaften.

÷ A~ist eine totale Funktion und A ein

Alphabet. c) t eVorb

(pl)k Nachb

(p12~) ist das Startelement

d) Ist t'e Vorb (pl) \Nachb t' ~ Nachb

(Soa)

Nachb

(Sob)

A

(pl), Nachb

m ~ M :~VK ~3

(p3) sind paarweise disjunkt.

(m, m).

(S2a)

p2 ist eineindeutlg.

(S2b)

Vorb

(S3a)

pa ist eineindeutig.

(S3b)

Vorb

(p2)C Nachb(p123).

(p3)CNachb

(pla).

ist rechtseindeutig.

(S4b)~ m , m i

(p12~) und t' # t, dann ist

(p2) und Nachb

pl ist eineindeutig.

~

Z~G~]&~.

(p~).

(s1)

(S4a)

~

EM

: (m , m ) ~ p ~ > ( m E N a c h b

2

1

2

(p123)\Vorb

(pl))

1

A(meVorb

(pl)\Nachb

(p123)).

2

1. Die Relationen p~

3. Wenn p ~

i < r < 4, sind asymmetrisoh

und irreflexiv

@, i < e <_ 3, dann gilt:

Vorb (p~)¢Naohb 4. Vorb (pl)f~Vorb

(p~) und Nachb

(J)¢Vorb (~).

(p~) = ~ und Nachb

(pl)f~Nachb

5. Die Relation p123 ist linkseindeutig.

(p4) = @.

154

6.

Wenn meFeld

(p123)\Nachb

dann ist m a V o r b

(pl2S),

(~l)\Nachb

7. Das Relationengebilde

(012S) und m ~ V o r b

(M, pl, 02, p3) ist eine endliche

zieller tern[rer Wurzelb[ume.

Ein Element m aus Feld

genau dann Wurzel eines Baumes, 8. Das Z-Gebilde

gerichteter

ziellen tern~ren Wurzelb~umen sind. Die Verbindungen Relation

wenn m ~ V o r b

Menge spe-

(p123) ist

(~1)\Nachb

(0123 ) ist.

(M, ~i , ~2, 0 3 , p , f, t) kann als ein knoten-

kantenbewerteter,

Graph aufgefa~t besteht,

werden,

ist (ms, mw)ep~,

und

der aus spe-

die miteinander

zwischen den Wurzelb~umen

04 festgelegt,

Wurzelbaums

(p23).

verbunden

werden durch die

dann ist m 5 Spitze eines

und mw Wurzel eines Wurzelbaums.

Es werden nun zwei Z-Gebilde Semantikgebilde

eingefNhrt,

das Syntaxgebilde

~

1

und das

~ 2.

3.2. Das Syntax~ebilde Ein Syntaxgebilde

al ist ein z-Gebilde

: ~I

= (MI' 011'0~,0~, 0~,ff

Da es dazu dienen soll, den Begriff Struktureinheit freien - Sprache mit der Grammatik

Es wurde schon erw~hnt, Ableitung

festgelegt

einer - hier kontext-

G = (N, T, R, s) zu pr~zisieren,

mu~ man noch einmal auf die Charakterisierung und Klassen yon Struktureinheiten

yon Struktureinheiten

zur~ckgreifen.

da~ eine Struktureinheit

durch eine spezielle

werden kann. Eine solche Ableitung

einem n E N wird durch spezielle

~ (n) zu

WGnsche des Sprachdesigners,

durch gewisse Vorstellungen

Gber die Semantik,

aus denen sich diese Satzform aufbaut,

sind nichtterminal bzgl.

oder terminal;

dieser Ab!eitung

zeichnet werden. es 'initial bzgl.

a (n)' oder

Entsprechend

'relativ-terminal

gen Ableitung

das Zeichen

,

[, <subscript

einer Ableitung

Definiert



bzgl.

sagen, da~ 'relativ-

der zu Figur Ib gehSri-

relativ-initial

~ (n) relativ-terminales

ist, ist relativ-initial

speziellen

deren Elemente

oder

~ (n)' be-

und die Zeichen

list> und ] sind relativ-terminal. bzgl.

man nun die zur Charakterisierung

angezogenen

~ (n)'

'terminal

bzgl.

kann man yon einem Zeichen

einer bestimmten Ableitung

~ (n)' ist. So ist z.B. bzgl.

nichtterminal

und liefert

sie kSnnen aber auch als

initial bzgl.

bzgl.

bestimmt

z.B.

eine Satzform.

Die Zeichen,

t I )"

Ableitungen

Zeichen ~, das zugleich einer Ableitung ~ (5).

der Struktureinheiten

dutch eine T e i l m e n g e ~ v o n

jeder Ableitung

Ein

in denen sie auftreten

her-

NUT, relativ-

155

terminal sind, so kann man auch durch~]~die Struktureinheiten charakterisieren und erh~it zugleich eine Unterteilung der Grammatik in Untergrammatiken. Da die Struktureinheiten als Einheiten im Hinblick auf die Semantik eingefNhrt und durch die M e n g e ~ d e f i n i e r t eine Teilmenge v o n ~ ,

werden, ist nicht nur T

sondern auch noch die Menge aller nichttermi-

nalen Zeichen bzgl. deren mindestens eine Regel aus R rekursiv ist. Dar~ber hinaus bestimmen innerhalb des durch das Axiomensystem festgelegten Rahmensweitgehend die eigenen Konzepte, welche sonstigen Zeichen Elemente v o n ~ s i n d . Bei gegebener kontextfreier Grammatik G und einer durch eine M e n g e ~ festgelegten Unterteilung von G k~nnen die Relationen p~

i
und die Funktion f durch einen Algorithmus bestim~t werden, der hier l nicht explizit angegeben werden soll. Statt dessen soil der Zusammen-

hang zwischen G, ~ u n d

~

1

an Hand eines Beispiels erl~utert werdeno

Gegeben sei die folgende Untergrammatiki£ der ALGOL 60-Grammatik in BNF: ::: : ::= I I I <procedure statement> ::= $oto <designational expression> ::= <empty> ~=

{, ~0to, <designational expression>, <empty>, <procedure statement>, ,

:, }.

Dadurch ist die Klasse aller Struktureinheiten zu festgelegt.

156

,I[

~

3

3 .........

Figur 2 Der Untergrammatik M

: {x I x 6

%{ zugeordnetes

~

A

Syntaxgebilde

17 _< x _< 28};

t : 17

I

Einige

1.

1

Anmerkungen

und Folgerungen:

Verb

(Pl 14)

+ N

Feld

(pll2ag)\Vorb

f (p

t~)

4 T

I

2. f

(t) I

3. Wenn

: S.

I

(m, [ ) e p4, dann ist f 1

4. Die Elemente

(m) : f 1

aus Naohb

(m). 1

(p 123)\ Verb

(pl), nach Axiom

1

eine Obermenge mente',

yon Verb

(p4) werden 'relativ-terminale Ele1 1 aus Verb ( p ) \ Nachb (p123)'relativ1 1 genannt. Daraus geht hervor, dab ein

die Elemente

initiale

Elemente'

E 1 e m e n t

nicht

tial sein kann.

Dagegen

Z e i e h e n , terminalen Zeiehen, initialen 5. Jedes

(S4b)

1

zugleich

relativterminal

istlnach 3.

das ist der Funktionswert

Element,

gleich

dem zugeh~rigen

das ist der Funktionswert

und relativini-

ein relativterminales in einem relativrelativinitialen

im zugehSrigen

relativ-

Element.

zu g e g e b e n e m ~ e i n e

Teilgebilde

eines

Untergrammatik

Syntaxgebildes

repr~sentierende

ist ein Syntaxgebilde.

157

6. Wird die gesamte ALGOL 60-Grammatik

durch ein Syntaxgebilde l

repr~sentiert,

so liegen in dem Beispiel

22, 25 und 27 yon M

im Vorbereich,

die Elemente

das Element

~9, 21,

17 im Nachbe-

1 reich der Relation

p4. Damit wird noch einmal auf die bereits 1

erw~hnte Bedeutung

der Relation

p4 verwiesen:

Sie bestimmt

die

1

Verbindung

zwischen den Teilgebilden,

Klassen von Struktureinheiten

die Untergrammatiken

repr~sentieren.

dargestellte

Syntaxgebilde

tureinheiten

mit relativinitialem Zeichen

Beim Durehlaufen

eines Syntaxgebildes

der die alternativen Strukturbaum

~

repr~sentiert

M~glichkeiten

bzw.

Das in Figur 2

die Klasse aller Struk
statement>.

erh~it man unter Ber~eksichtigung

bestimmenden

Relation

und als dessen Terminalzeiehenreihe

aus L. T baut sich aus den beim Durchlaufen

p3 einen I ein Programm

der Wurzelb~ume

anfallen-

den Struktureinheiten

auf. Damit ist auf der Seite der Syntax der Be-

griff Struktureinheit

formal erfaSt.

3.3. Das Semantiksebild e Es ist nun noeh notwendig, Form einer Obersetzung gender

~bersetzten

jeder Struktureinheit

der Struktureinheit

Struktureinheiten

in einer bedeutungstragenden deutung

b(~) definiert

Das Semantikgebilde

O ~-(M, 2

f

2

012, P22, p3

,

p

in

und das Zusammenf~-

zu erm~gliehen.

Damit kann dann

zu einem Element

~ 6 L seine Be-

werden.

a 2 ist ebenfalls

2

: Feld

Sprache

eine Bedeutung

zuzuordnen

4 , T~2 ,

t

2

ein ~ - G e b i l d e :

) 2

(~123~) + A~ ist eine totale Funktion.

2

2

Die Begriffe

2

'relativinitial'

aueh in Semantikgebilden Ein Semantikgebilde,

und

'relativterminal'

werden entsprechend

benutzt.

das als eine Obersetzung

des Syntaxgebildes I

angesehen wird,

soll ein zu ~

korrespondierendes Semantikgebilde i ( a ) gekennzeichnet werden.

genannt werden und durch ~ 2

Def.

i

2 Ein zu ¢

korrespondierendes Semantikgebilde ~ ( ~ ) kurz I 2 i Semantikgebilde zu ~ - ist entweder ein isomorphes Bild yon I unter h : M + M mit h ( t ) = t oder ein Gebilde, das aus I

I

2

1

einem zu ~ k o r r e s p o n d i e r e n d e n tare Transformation

2

Semantikgebilde

hervorgeht.

durch eine elemen-

158

Elementare Transformationen mantikgebilde ~

(~) 2

:{

an dem zu ~ (M , pl 2

I

IP3' P~

, 02

2

korrespondierenden

2

2

f2 ,

,

t

2

)

Se-

:

2

(I) Voraussetzung:

V m 4 : (m , m ) ~ pz A m ¢ Vorb (p1~). 1 2 2 Transformation: 'Entferne m aus 6" ( ~ ) ' 2 1 : ~ p2 := p2 \ {(m , m)}. 2 2 1 Wenn ~/m2 : (m~ m 2) E P22, (p~\{(m,

dann p22 := (~) Voraussetzung:

Vm

eNachb

(p t 2 3 ) /~ m ~ M 2

1

Transformation:

m2)})U{(m~,

'F~ge m nach m : ~ Wenn

Vm

2

(3) Voraussetzung:

2

in ~

( ~ ) ein' 1 2 ! : (m , m )& p2 1

2

:= 02 U{(m{,m 2

2

1'

2

2

Feld ( p l Z 3 g ) .

2

dann p2 := ( p ~ \ { ( m ~2

~

m2)}) U { ( m

(m, n).

Sei (m, m )e p2 und (m , n ) ~ 2

, m~}.

)}.

V m, n e Feld (P22)AVK22

Transformation:

m~)}.

2

3

2

P2"

'Vertausche m und n in ~ { ~ )' 2 i :4 Wenn V m dann

O2 2

4

:

;=

(n,

m ) e p2 4 2

(p2 \{(n, 2

m )})

4

U {(m,

m )}.

4

P22 :: (p22 \{(m, m2) , (m3, n)})"

u{(n, m 2 ), (m3 ' m)}. {

F~r i

::

1,

2,

3:

Wenn Vm

1

:

(m , m) e p 1

dann p2t :: (p2{ \{(ml, Wenn V m

5

:

(m,

2

,

m)})u{(ml,

n)}.

m ) ep a 5 2~

dann 0 3 :: {p 3 \{(m, m )})I]{(n, m )}. 2

2

5

5

159

Wegen der Zul~ssigkeit

der Vertauschungstransformation

die relativterminalen,

nichtterminalen

Elemente,

ist es notwendig,

d.h. die E!emente aus

dem Vorb

(p~) und Vorb (p4) einander explizit zuzuordnen. i 2 durch die 'Assoziationsrelation' pl : ~ { ( x , y) I x g V o r b 12

Das geschieht (p4)^y = h (x)}. l

Durch diese Zuordnung von ~

und @ ( @ ) erh~it nicht nur jedes eine 1 2 1 Klasse yon Struktureinheiten repr~sentierende Teilgebilde (d.h. jeder Wurzelbaum) tureinheit

von 6 eine Obersetzung zugeordnet, sondern auch jede Struk1 und damit die zugehSrigen terminalen bzw. relativterminalen

Zeichenreihen.

Denn das Durchlaufen

eines Semantikgebildes

durch das Durchlaufen des Syntaxgebildes

6

1

zu g i s t 1

eindeutig bestimmt.

4: BeisPiel Zur Veranschaulichung von A h o u n d

Ullman

der eingef~hrten

[I] angegebenen

Begriffe

Beispiel einer ~bersetzung

schreibung mit Hilfe eines Ubersetzungsschemas Hilfe von Syntax- und Semantikgebilde a) ~bersetzungsschema

~:~

soll in einem einfachen der Be-

~-die Beschreibung mit

gegen~ber gestellt werden.

({S}, {a, +}, {a, +}, {as +}, R, S).

(i)

R : ~ { S ÷ + S ~l) S (z) , S d ) + S(zl; S ÷ a, a}. In der folgenden aus ~ abgeleiteten nichtterminale

0bersetzung werden assoziierte

Zeichen dutch den gleichen Index gekennzeichnet.

Da-

dutch m~ssen jeweils vor Anwendung der ersten Rege! die Indizes ge~ndert werden. Beispiel einer Ableitung: (S, S) -9 (+ S ~n

S (2) , S(I)

+ S(2) )

--~ (++ S (3) S C~) S(2), S {~) + S (4) + S(2) ) --9 (++ aS (~) S (2) ~ a + S (W

+ S(2) )

--~ (++ aaS, a + a + S) (++ aaa, a + a + a).

b) Be± Verwendung von Syntax- und Semantikgebilden

kann jedes in dem Ge-

bilde als Funktionswert yon fl auftretende Zeichen als Individuum identifiziert werden. Die Assoziationsrelation pl besteht aus den 12 Paaren assoziierter Elemente aus Vorb (p~) bzw. Vorb (p4) und erf~llt dieselbe Aufgabe wie die wechselnden leitungsschemas.

1

2

Indizes in den Regeln des Ab-

160

/I //

//'/I

Ill++"

"

4/

/ I

~

i / ~i/ 4/

3

3

............

k

J

\

7

Figur 3a Syntaxgebilde zu (I): t

: I

v2Js

I

Figur 3b Semantikgebilde zu (I); t : 10

1

Die Assoziationsrelation

4Z

5

2

ist pl = {(3, 12), (4, 14)}. 12

~. ~

Figur 4a Strukturbaum ~ zu (2)

5

Figur 4b Obersetzung des Strukturbaums

Mit Hilfe des Strukturbaums ~ und seiner Obersetzung wird die Terminalzeichenreihe ~ = + + a a a yon ~ in a + a + a, die Bedeutung b (~) yon ~, ~bersetzt.

161

Schlu~bemerkunsen Die EinfHhrung

der Begriffe

Syntaxgebilde

erster Schritt auf dem Weg, die gesamte grammiersprache

mit Hilfe yon Relationengebilden

sind jedoch weitere

Relationengebilde

turen zur Identifizierung Daten' bzw.

und Semantikgebilde darzustellen.

erforderlich,

deklarierter

zum 'Zugriff auf Daten'

ist ein

Syntax und Semantik einer Pro-

GraVen und zur

dienen.

Dazu

die als Hilfsstruk'Speicherung

Die Bedeutung

yon

eines aus

einem Syntaxgebilde ~ abgeleiteten Programms ist dann durch die, siI multan mit diesem P r o g r a ~ in dem zu ~ gehSrigen Semantikgebilde I

(a) 2

abgeleitete,

terminale

Zeichenreihe

bestimmt.

Jedes

'Zeichen'

I

dieser Reihe ist ein Element

aus A~ und stellt eine Folge elementarer 2

Befehle

dar.

Wesentliche

Bestandteile

sind Operationen

der hierbei bendtzten

an Relationengebilden. recht umfangreich

Die in der Existenz mende ~hnlichkeit mationen, se Gebilde

in Kauf nehmen,

von Syntax- und Semantikgebilde

Durch die Definition

z.B. verkleinert

daraus eine M~glichkeit, Zwecke merklich

zum Ausdruck

kom-

von Syntax und Semantik legt aber

die simultan an beiden Gebilden ver~ndert

da5 die

werden.

der Beschreibung

noch einen anderen Gedanken nahe:

Sprache

Die Sprache kann dadurch sehr

einfach sein; man mu~ aber m6glicherweise Hilfsstrukturen

semantischen

von Transfor-

auszufHhren

werden.

sind, k~nnen die-

Vielleicht

die gesamte Sprachbeschreibung

ergibt

sich

f0r bestimmte

zu vereinfachen.

Literatur [I] Aho, V.H., Ullman J.D.: compiling. [2] Naur, P.

Vol.

The theory of parsing, translation,

I. Englewood

Cliffs

(N.J.):

Prentice-Hall

(ed.): Revised report on the algorithmic

ALGOL 60. Numer.

and 1972.

language

Math. ~, 420 - 453 (1963).

Dr. Wolfgang Niegel Mathematisches Institut Technischen Universit~t 8ooo M~nchen 2 Arcisstr.

21

der M~nchen

ALSl - EINE HUHEREPROGRAMMIERSPRACHE ZUR TRANSFORMATIONVON ALGOL 68-VERBUNDENIN SIMULA-KLASSEN U. KASTENS

1. Ei.nf.Uhrun~ Die vergleichende Betrachtung von ALGOL 68 und SlMULA zeigt, dab diese Programmiersprachen in einigen grundlegenden Sprachelementen wie den Datenstrukturen verwandte Eigenschaften haben. Es l i e g t daher nahe, die M~glichkeiten der Transformation zwischen diesen Sprachen zu untersuchen. Das Resultat solcher BemUhungen i s t die Definition der h~heren Programmiersprache ALSl (ALGOL 68, SI__MULA)ZKa73], die einen gro~en Teil von ALGOL 68 mit dem Verbundkonzept als Kern enth~It und die Bedingung der Obersetzbarkeit in SIMULA e r f U l l t . Im Folgenden sollen zun~chst ALGOL 68-und SIMULA-Datenstrukturen vergleichend gegenUbergestellt werden. Dabei beziehe ich mich noch auf die ursprUngliche Definition von ALGOL 68 in [Wi69] nicht auf die 1973 revidierte Fassung.

2. GegenUberstellung der Datenstrukturen Die Definition der elementaren Datenobjekte stimmt in beiden Programmiersprachen nahezu Uberein. Das Konzept der zusammengesetzten Objekte i s t in ALGOL 68 "orthogonal" in die Ubrigen Spracheigenschaften i n t e g r i e r t , w~hrend bei SIMULA das Klassenkonzept historisch aus den Problemen der Simulation diskreter Systeme entwickelt und auf ALGOL 60 aufgepflanzt wurdeo In ALGOL 68 werden Objekte nachihrer "Art" (mode) unterschieden, die im Wesentlichen f e s t l e g t , welche Operationen auf ihnen ausfUhrbar sind. Wir wenden im Folgenden diese Terminologie auch auf SIMULA an.

2.1Verbunde Unter Verbunden verstehen wir zusammengesetzte Objekte, auf deren Komponenten direkt durch Angabe einer Komponentenbezeichnung zugegriffen werden kann. In ALGOL 68 unter-

163

l i e g t die Art der Komponenten keinen speziellen Einschr~nkungen, mit der Ausnahme, dab ein Verbundobjekt kein Objekt von gleicher Art enthalten kann. Die Art eines Verbundobjektes wird bestimmt

durch die Komponentenarten und -bezeichnungen und die Anzahl

und Reihenfolge der Komponenten. Das folgende ProgrammstUck zeigt die Vereinbarung eines Verbundobjekts und Zuweisungen an dessen Komponenten struct (real radius, struct (real x,y) mittelpunkt) k:= (1,(0,0)); radius of k : : 1.5; mittelpunkt o f k:= (1.0, 2.0)

In ALGOL 68 kann durch Artvereinbarung fur Verbundarten (wie auch fur andere Arten) eine Bezeichnung eingefUhrt werden. Die Vereinbarungen struct kreis = (real radius, punkt mittelpunkt); struct punkt = (real x,y); kreis k:=(1,(O,O)) haben zusammen die gleiche Bedeutung wie die Vereinbarung im obigen Beispiel. Diese Artbezeichnungen sind nur als Kurzschreibweise fur die vollst~ndige Artangabe zu verstehen; siesindkein unterscheidendes Merkmal der Art. Es i s t deshalb m~glich, dab Arten, die verschieden angegeben werden, gleich sind: struct ml = (real k, ref m2 e) struct m2 = (real k, ref ml e) Der Obersetzer muB solche, und auch komplexere F~lle erkennen (Artidentifizierungsalgorithmen von Koster [Ko69] und Zosel [Zo71]). Zusammengesetzte Objekte werden extern durch Angabe einer Liste der Komponenten notiert. Da weder die Art noch Komponentenbezeichnungen in dieser Notation angegeben werden, i s t es Aufgabe des Obersetzers, aus dem Kontext zu ermitteln, von welcher Art das Objekt i s t . In SlMULA i s t die Wiedergabe von ALGOL 68-Verbunden m~glich durch entsprechende Spezialisierung des m~chtigeren Klassenkonzeptes. Das oben betrachtete ProgrammstUck kann etwa so formuliert werden:

class kreis (radius, mittelpunkt); real radius; re_f_f(punkt) mittelpunkt;; class punkt (x,y); real x , y ; ; ref (kreis) k; k:-new kreis(1, ne___ww punkt (0,0)); k.radius::l.5; k.mittelpunkt.x:=l.O; k.mittelpunkt.y:=2.0; Enth~It ein Verbund einen anderen Verbund als Komponente, so i s t das in SIMULA durch einen entsprechenden Verweis auszudrUcken. Dabei wird ausgenutzt, dab das "r~umliche Enthalten" und das "Verweisen" gleichwertige Implementierungen desselben Prinzips sind. AuBer dem Generierungsoperator gibt es in SIMULA keine Operation, die ein Klassen-Objekt als Einheit behandelt. Das Zuweisen von Verbundwerten erfolgt deshalb komponentenweise. Da die explizite Vereinbarung yon Klassen mit Zuordnung einer Klassenbezeichnung vorgeschrieben ist, existiert das Problem der Artidentifikation hier nicht.

Die Anwendungsm~glichkeiten von Klassen gehen Uber die Realisierung von Verbundobjekten hinaus, denn innerhalb einer Klassenvereinbarung k~nnen Anweisungen angegeben und Prozeduren vereinbart werden, die dann selbst Verbundkomponenten sind. Mit diesen Hilfsmitteln kann z.B. eine einfache Kellerorganisation folgendermaBen implementiert werden: class keller (laenge); integer laenge; be~inar_.r.~.~ a (l:laenge); "int.e~er pegel; boolean v o l l , leer; real procedure pop; begin pop:=a(pegel); pegel:=pegel-1; leer:=pegel=O end; procedure push (x); real x; begin pegel:=pegel+l; a (pegel):=x; voll:=pegel=laenge end.; pegel:=O; voll:=false; leer:=true

end Ein solches Objekt wird z.B. durch die Anweisung s:-new keller (100)

165

generiert. Zugriffe auf Elemente dieses Kellerobjektes k~nnen dann z.B. so formuliert werden i_f no___tts.voll then s.push (3.4) oder

i f not s.leer then y::s.pop

Die Methode, mit der der Keller imp]ementiert wurde, braucht auBerhalb der Klassenvereinbarung nicht zur Kenntnis genommen zu werden - es h~tte ebenso gut eine lineare Liste statt einer Reihung verwendet werden k~nnen (vergleiche Parnas [Pa72]). Nach dem gleichen Prinzip werden in SIMULA die Standardklassen SIMULATION und SIMSET d e f i n i e r t , die Datenstrukturen und Operationen zur Simulation bzw. Listenverarbeitung bereitstellen. Anwendungen dieser Art legen es nahe, eine Klassenvereinbarung aufzufassen als die Def i n i t i o n einer Datenstruktur zusammen mit den auf ihr ausfUhrbaren Operationen in geschlossener Form. In ALGOL 68 i s t ein analoges Konzept nicht vorhanden. Der Aufbau einer ~hnlichen Konstruktion macht dort erhebliche formulierungstechnische Schwierigkeiten. Verbunde k~nnen zwar Prozedurvariablen als Komponenten enthalten; die Prozeduren mUssen abet jeweils bei der Generierung eines solchen Verbundes von auBen zugewiesen werden. Im letzten Beispiel haben wir den Anweisungsteil der Klassenvereinbarung nur zur Initialisierung der Komponenten verwendet. Durch geeigneten Aufbau des Anweisungsteiles kann eine Klasse eine oder mehrere gleichartige Koroutinen definieren; z.B. das f o l gende vereinfachte Produzent-Konsument-System: class produzent be~in i n i t i a l i s i e r e

class konsument ;

begin i n i t i a l i s i e r e ;

detach; while bedingung do

detach; while bedingung do

begin produziere; resume (k)

begin verbrauche; resume (p)

end end

end end

Eine weitere Anwedungsm~glichkeit von SIMULA-Klassen l i e g t in der Erzeugung p a r t i e l l parametrisierter Prozeduren. Die im folgenden Beispiel definierte Klasse erzeugt abh~ngig von den Parametern entsprechende Polynomfunktionen, die z.B. in einer Integrationsprozedur ausgewertet werden:

166

class polynom (grad, koeffizieten); integer grad; ar__EZ~ "ykoeffizienten; begin real procedure polynomwert (x); value x; real x; begin real s; integer i ; s:=koeffizienten (grad); for i:=grad-lst_s_t#_E-1 until 0 do s:=s*x+koeffizienten ( i ) ; polynomwert:=s end end Ein Aufruf der Integrationsprozedur k~nnte dann z.B. lauten integral (new polynom (5, koeff ).polynomwert, 0.5, 2.1) Derartige Konstruktionen sind in SIMULAm~glich, da alle Objekte unbeschr~nkte Lebensdauer haben, w~hrend in ALGOL 68 als Kellersprache solche partiell parameterisierbaren Prozeduren nicht formuliert werden k~nnen.

2.2 VereinigungsarteE FUr eine Reihe von Anwendungen ist es erforderlich, Variable

zu haben, die Objekte

von unterschiedlicher Art als Inhalte besitzen k~nnen. In ALGOL68 wird die Art einer solchen Variablen ausgedrUckt als ein Bezug auf die Vereinigung der Arten, die die m~glichen Werte annehmen k~nnen, z.B. ref union (real, int, ref formel) In der ursprUnglichen Definition von ALGOL68 sind die Uber den einzelnen Arten definierten Operatoren nicht auf Objekte der union-Art anwendbar, vielmehr muB man erst mit einer speziellen Zuweisung("conformity relation") das Objekt an eine Variable der betreffenden Teilart zuweisen. In SIMULAwird die Vereinigung verschiedener Arten auf Klassen beschr~nkt. Mit Hilfe yon Pr~fixen in den Klassenvereinbarungen k~nnen Hierarchien yon Klassen definiert werden. Wollen wir z.B. eine Listenstruktur aufbauen aus Elementen, die unterschiedliche Komponenten haben wie die Klassen class listeleml (nachf, k); ref (listelem) nachf; integer k;; class listelem2 (nachf, c); ref (listelem) nachf; character c; so k~nnen wir die beiden Klassen zu einer "Oberklasse" zusammenfassen:

167

class l i s t e l e m (nachf); r e f ( l i s t e l e m ) nachf;;

listelem

class l i s t e l e m l ( k ) ; inte~..er k ; ;

listelem

class l i s t e l e m 2 ( c ) ; character c ; ;

Die in beiden Unterklassen gleiche Komponente (nachf) kann in der Oberklasse d e f i n i e r t werden. Der Z u g r i f f auf Komponenten, die in der Unterklasse d e f i n i e r t sind e r f o r d e r t , dab entweder die Klassenbezeichnung als"Qualifikation"angegeben oder das Objekt - wie in ALGOL 68 - an eine geeignete Variable zugewiesen wird. 1 qua l i s t e l e m l , k oder

11:-I; ll.k

Nach dem gleichen Schema i s t eine Hierarchie yon Standard-Klassen zur Organisation der Ein- und Ausgabe definiert. Jedem Datei-Typ i s t eine Klasse zugeordnet, die die j e w e i l i g e n Bearbeitungsprozeduren als Komponenten e n t h ~ l t : class f i l e file

...

class d i r e c t f i l e

f i l e class i n f i l e

...

...

f i le class o u t f i l e . . . o u t f i le class p r i n t f i l e

...

o u t f i le class punchfile . . . Die Artvereinigung aus ALGOL 68 kann in SIMULA durch die D e f i n i t i o n einer Oberklasse ohne Komponenten d a r g e s t e l l t werden: union m : (m~l, m2) e n t s p r i c h t den Klassenvereinbarungen class m;; m class ml . . . . m class m2. . . .

2.3

Reihungen

In SIMULA wurde das Array-Konzept unver~ndert aus ALGOL 60 Ubernommen. ALGOL 68Reihungen weichen davon vor allem nur in den folgenden Punkten ab: - Der Deskriptor einer Reihung i s t auf der Programmebene insoweiz zug~nglich, dab die Indexgrenzen abgefragt und im Falle yon flexiblen Grenzen auch ver~ndert werden k~nnen. Durch Erzeugen eines ver~nderten Deskriptors k~nnen die Indexgrenzen "getrimmt" bzw. Reihungsausschnitte definiert werden. Operationen mit Reihungen als Einheiten, insbesondere Zuweisungen sind m~glich.

168

-

Reihungen k~nnen e x p l i z i t als Folgen von Elementen angegeben werden, z.B. [1:4] i n t a = (1,2,3,4) [1:2, 1:3] i n t b : ( ( 1 , 2 , 3 ) , ( 4 , 5 , 6 ) )

2.4 Namen In der Algol 68-Terminologie werden unter "Namen" Verweise auf Bezugsobjekte im Sinne von Variablenadressen verstanden. Das Namenskonzept basiert auf einer strengen Hierarchie: Mit der Referenzstufe eines Namens i s t die Anzahl der indirekten Adressierungss c h r i t t e festgelegt, die n~tig i s t um ein Bezugsobjekt zu erreichen, das kein Name i s t . Die Referenzstufe eines Namens und die Art des Bezugsobjektes bestimmen die Art des Namens. Allen Objekten - auch Namen und Konstanten - k~nnen durch Vereinbarungen Bezeichnungen zugeordnet werden. Namen von Komponenten s t r u k t u r i e r t e r Objekte sind ebenfalls durch Bezeichnungen i d e n t i f L zierbar, z.B.: r e f i nt i = k of v r e f i n t j = a [4] Die M~glichkeit, Namen zu definieren, die auf Namen verweisen, w i r f t das Problem der "Verschleppung" von Namen auf, deren Bezugsobjekte nicht mehr e x i s t i e r e n . Das folgende ProgrammstUck i s t ein einfaches Beispiel dafUr: ref r e f i n t i i

= ref int;

be_be_~_inr e f i n t k = i n t : = 5 ; ii

:=k

en_d_d; print ( ii ) In der Zuweisung i i : = k wird der k zugeordnete Name an i i zugewiesen, dessen GUltigkeitsbereich den von k umfa~t. Um das Kellerprinzip aufrecht zu erhalten, mu~ ein Z u g r i f f auf das nic~t mehr existierende Objekt (in p r i n t ( i i ) )

verhindert werden. Hierzu w~ren

i n e f f i z i e n t e LaufzeitprUfungen n~tig; es wird deshalb die st~rkere Forderung g e s t e l l t : Der Name eines Objekts darf nicht an einen Namen zugewiesen werden, der eine gr~6ere Lebensdauer hat, als das Objekt selbst. In SlMULA i s t kein so strenges Referenzstufen-Konzept d e f i n i e r t wie in ALGOL 68. FUr Klassenobjekte existieren Namen der Referenzstufe I u n d Variable dafUr. Bei Objekten

169

einfacher Art wurde das Variablen-Prinzip aus ALGOL 60 Ubernommen. Wegen dieser unterschiedlichen Definition i s t es erforderlich, bei der Transformation alle Objekte durch Klassen zu implementieren, um einheitliche Referenzstufen darzustellen. Das Problem der Verschleppung von Namen e x i s t i e r t in SIMULA nicht, da alle Objekte unbegrenzte Lebensdauer haben. Der Vergleich auf Identit~t i s t in ALGOL 68 und SIMULA die einzig m~gliche Operation mit Namen als Operanden.

3. Transformation der Datenstrukturen Bei der Transformation von ALGOL 68-Datenstrukturen in SIMULA-Klassen i s t die Realisierung des Referenzstufenkonzeptes, der Identifizierung von Namen und der Artanpassungsoperationen die wichtigste Aufgabeo Die Ubrigen Zuordnungen k~nnen im allgemeinen durch Textsubstitution vorgenommen werden. Die Darstellung beliebig langer Verweisketten durch Referenzvariable bereitet keine prinzipiellen Schwierigkeiten, da sie aus mehreren Verweisen kettenartig zusammengesetzt werden k~nnen. Objekte der Referenzstufen 0 und 1 k~nnen durch gleichartige Klassenobjekte r e a l i s i e r t werden, lhre externe Identifizierung erfolgt durch eine Referenzvariable. Benannte Objekte der Referenzstufe 0 werden dann als schreibgeschUtzte Variable aufgefa~t. Diese Unterscheidung kann vom Obersetzer vorgenommen werden. Auf gleiche Weise i s t das Problem zu l~sen, da# in SIMULA Verbundkomponenten nicht wiederum Verbundkonstante sein k~nnen: Es wird stattdessen eine Referenzvariable als Komponente angegeben, deren Wert ein unver~nderlicher Verweis auf ein entsprechendes Objekt ist. Objekte der Referenzstufe 2 werden dargestellt durch Klassenobjekte, die als einzige Komponente eine Referenzvariable vonder entsprechenden Art besitzen. Damit ergibt sich das folgende Abbildungsschema: Sei m eine beliebige Art. So entsprechen der ALGOL 68-Artvereinbarung mode vb = struct (~ ko, ref m kl, ref ref m k2) die Klassenvereinbarungen class vb; be~in ref (m) ko; ref (ref m) kl; ref (ref m) k2; >Zuweisungsprozedur< end

>Initialisierung<

170

und class refvb; begin re___~f(vb) verweis; end

Die im Klassenrumpf definierte Zuweisungsprozedur fUhrt die komponentenweise Zuweisung eines Verbundes aus. Namen von Referenzstufen h~her als 2 k~nnen nach dem gleichen Prinzip (durch EinfUhrung weiterer Klassen) dargestellt werden. Bei unserer Implementierung haben wir davon abgesehen, da man im allgemeinen mit den Referenzstufen 0,1 und 2 auskommt. Die in ALGOL 68 definierten Artanpassungsoperationen k~nnen weitgehend durch Operationen auf den Klassenobjekten r e a l i s i e r t werden: z.B. entspricht dem "Dereferenzieren" von Referenzstufe 2 auf i das Verfolgen der Referenz, die durch die Komponente "verweis" gegeben i s t , "Vereinigen"(uniting) wird durch entsprechende Qualifikation des Objektes erreicht, "L~schen" (voiding) durch Zuweisung an geeignete Variable, die "universelle Artanpassung" (hipping) und "Weiten" durch Generierung geeigneter neuer Objekte. In unserer Implementierung haben wir auf die Transformation der Anpassungsoperationen "proceduring" und "rowing" verzichtet, und - wie in SIMULA - gefordert, dad Verbundarten durch eine Artbezeichnung i d e n t i f i z i e r t werden, um so die Verfahren zu vereinfachen, mit denen die jeweils n~tige Artanpassung festgestellt wird.

4. Transformation der Pro~rammstrukturen Eine Reihe von Sprachelementen sind in ALGOL68 und SIMULA identisch oder k~nnen leicht auf entsprechende Eigenschaften abgebildet werden: z.B. Zuweisungen, Formeln, bedingte Formeln, Fallunterscheidungen (Transformation in SIMULA-Switch-Konstruktion bzw. "if-Kaskaden"), Wiederholungsanweisungen, SprUnge, Generatoren, Vereinbarungen und Prozeduren. Es ist bemerkenswert, dad die ParameterUbergabe aus ALGOL68 aufgrund der gew~hlten Transformation der Datenobjekte ohne Schwierigkeiten durch die ParameterUbergabe "byreference" (dem Wertaufruf auf Referenzstufe i) in SIMULAwiedergegeben werden kann. Auf die Abbildung von ALGOL 68-Sprachelementen, die in SIMULA nicht in entsprechender Bedeutung existieren wurde verzichtet (so z.B. auf Identit~t von Ausdruck und Anweisung, Operatordefinitionen, parallele Bl~cke, ALGOL 68-E/A und Prozeduren als Datenobjekte). In Prinzip k~nnten auch~iese Spracheigenschaften auf SIMULA transformiert werden, z.B. indem man Prozeduren als Klassen d a r s t e l l t und dann wie Verbunde als Datenobjekte behandeln kann.

171

5. Aufbau des Obersetzers Die im Vorangehenden kurz erl~uterten Sprachelemente sind zu der in [Ka73] definierten Sprache ALSl zusammengefaBt. FUr diese Sprache wurde in SIMULA ein Obersetzer geschrieben, der ALSl-Programme in SlMULA Ubersetzt. Er ist in fUnf Koroutinen gegliedert, die wie in der folgenden Abbildung dargestellt zusammenwirken: -- ALSI-Programm I y

Lese-

m-~-r°graim ~ t a

V

Fehlerbehandlneungsrouti

Zwi schencode i n I

"

~

° u t iArtprUfungsL_~ l ne $ ........ .

Ringspeicher

abstrakter I

Programmbaum a b s t r . Programmbaum, Verei nbarungsl i sten,Arti nformati on

[--~exterzeugungs-I m__[routine

m SlMULA-Programm

Das Leseprogramm fUhrt die lexikalische Analyse durch und tr~gt einen Zwischencode in einen Ringspeicher ein. Der Syntaxanalysator arbeitet im "recursive-descendent"- Verfahren (ohne "backtracking") und baut aus dem Zwischencode einen abstrakten Programmbaum auf. Die ArtprUfungsroutine fUgt Vereinbarungslisten in den Baum ein, ermittelt die Arten der Objekte und fUhrt die Artanpassung durch. In der Texterzeugungsroutine werden aus dem abstrakten Program~baum die SIMULA-Programmtexte aufgebaut. Weil das erzeugte SIMULA-Programm die gleiche Struktur wie das Quellprogramm hat, k~nnen die Texte von rekursiven Prozeduren modular aus Teiltexten zusammengesetzt werden. Die Routine zur Fehlerbehandlung kann yon allen anderen Routinen aktiviert werden. Sie gibt die Me~dungen aus, bestimmt bei syntaktischen Fehlern den Aufsetzpunkt und reaktiviert die entsprechende Syntaxprozedur. FUr das Zusammenwirken der Koroutinen wurde die Strategie verfolgt: Jede Routine ist

1'-/2

solange aktiv bis sie genUgend Information beschafft hat, mit der die n~chste Routine sinnvoll arbeiten kann. Dadurch wird gew~hrleistet, dab sich immer nur das notwendige Minimum an Informationen Uber das Eingabe-Programm im Speicher befindet. Der Umfang des ALSI-Obersetzer-Programmes und die Obersetzungszeiten liegen in der gleichen Gr~Benordnung wie beim SIMULA-Obersetzer. Die erzeugten SIMULA-Programme haben - abgesehen von den komplexeren Klassenvereinbarungen - etwa das gleiche AusmaB wie die ALSI-Quellprogramme; sie ben~tigen wegen der nicht effizienten Darstellung yon einfachen Werten und Reihungen durch Klassen mehr Rechenzeit (der erh~hte Speicherbedarf bei der AusfUhrung schl~gt sich wegen der h~ufiger n~tigen Speicherbereinigung auch in der Rechenzeit nieder). 6. Literatur [ DMN71] O.J. Dahl, B. Myhrhaug, K. Nygaard: SIMULA 67 COMMONBASE LANGUAGE, Norwegian Computing Center, pub. S-22, 1971 [Ka 73] U. Kastens: ALSI - Zine h~here Programmiersprache zur Transformation yon ALGOL 68-Verbunden in SIMULA-Klassen, Universit~t Karlsruhe, Fakult~t fur Informatik, Diplomarbeit, M~rz 1973 [Ko 69] C.H.A. Koster: On INfinite Modes, Algol Bulletin AB 30.3.3, Feb. 1969 [Pa 72] D.L. Parnas: On the Criteria To Be Used in Decomposing Systems into Modules, CACM, Dec. 1972 [Ro 73] H.Rohlfing: SIMULA - Eine EinfUhrung, Bibliographisches

Institut,

HochschultaschenbUcher, 1973 [Wi 69] A. van Wijngaarden (Editor), B.J. Mailioux, J.E.L. Peck, C.H.A, Koster: Report on the Algorithmic Language ALGOL 68, Numerische Mathematik, 14_, 79-218 (1969),Springer-Verlag [Zo 71] M.E. Zosel: A Formal Grammar for the Representation of Modes and its Application to ALGOL 68, University of Washington, Computer Science Group, Dissertation, 1971 Anschrift des Verfassers: Dipl.-Inform. Uwe Kastens, Universit~t Karlsruhe, Fakult~t fur Informatik, D-7500 Karlsruhe, Zirkel 2

INTERAKTIVES TRACE- UND DEBUGGING-SYSTEM ALGOL KIEL X8 J. BAGiNSKI UND H. SEIFFERT

Die algorithmische Formelsprache ALGOL 60 erleichtert rung von Rechenverfahren fGr Digitalreehner,

die Programmie-

da sie maschinenunabh~n-

gig ist und der Benutzer die jeweilige Maschinensprache nen braucht. Die erforderliche Programmierarbeit lich verringert.

nicht zu ken-

wird dadurch erheb-

Bei der Herstellung ven umfangreicheren ALGOL-Pro-

grammen ist jedoch im allgemeinen mit erheblichem Zeitaufwand fGr die Suche nach Programmierfehlern Das Betriebssystem

zu rechnen.

sell daher so beschaffen sein, da~ der zum Auffin-

den der Fehlerursachen fttr den Programmierer erforderliche Aufwand m~glichst gering gehalten wird. Zu diesem Zweck wurde das als Subsystem im Betriebssystem

der Kieler EL-X8~3]enthaltene ALGOL-System

um zwei Meduln erweitert.

Der TRACE- und DEBUGGING-Modul gestattet

eine Analyse des Programmablaufs, Generierung,

das Dialegsystem ~EDEA dient zur

Ausftthrung und Ab~nderung von ALGOL-Objektprogrammen.

Teil I: Der ALGOL TRACER I. EinfGhrunff Der ALGOL TRACER ist ein Hilfsmittel grammierfehlern.

Ausgangspunkt

ALGOL 60-Programm,

zur Auffindung yon logischen Pro-

ist daher ein syntaktisch richtiges

das heigt, beim Compilieren dGrfen keine Fehler

festgestellt worden sein. Eine interpretative Programmausftthrung ist wegen zu heher Rechenzeit unrealistisch.

Der TRACER fGhrt daher das

vom Compiler erzeugte Objektprogramm abschnittweise unter der Kontrolle des Benutzers aus. Der Compiler und der Sourcetext werden dabei nicht mehr ben~tigt. Es ist daher auch nicht m~glich,

den Objektcode des zu

untersuchenden ALGOL-Programms nachtr~glich abzu~ndern.

Sollte auf-

grund der vem TRACER gelieferten Informationen eine Programm~nderung erforderlieh werden, so mu~ der Soureetext neu eompiliert werden. Der Vorteil dieser Methode

ist, da~ sich fGr das zu untersuchende

Programm keine Einschr~nkung bezGglich der Syntax von ALGOL 60 ergibt und dag sich der Speicherplatzbedarf und die Rechenzeit gegenGber der

1 V4

normalen Programmausftthrung nicht erh~hen. Die Kommunikation mit dem TRACER geschieht auf der Grundlage des Sourcetextes, so da2 der Benutzer keine Kenntnisse Gber den ~ e r s e t z u n g ~ e r g a n g ben~tigt. ])as bedeutet zum Beispiel, da2 Namen und Zeilennumerierung des Sourcetextes verwendet werden. 2. Betriebsarten 2.1. Diaio~betrieb Das effektivste Verfahren bei der Fehlersuche ist das DEBUGGING. Der Programmablauf wird durch den Dialog mit dem TRACER Gberwacht und beeinflu2t. Man verf~hrt dabei so, da2 man dem TRACER von einem Fernschreiber aus einen Auftrag er~eilt. In Abh~Lmgigkeit vom Ergebnis der Ausftthrung dieses Auftrages kann dann der n~chste Auftrag erteilt werden. Der entscheidende Vorteil des DEBUGGINGS im Dialogbetrieb ist die M~glichkeit der Programmbeeinflussung durch Entscheidungen~ die der Benutzer erst w~hrend des Reehenlaufs trifft, nachdem er durch den TRACER schon Informationen Gber sein Programm erhalten hat. 2.2. BATCH-Betrieb TRACING ist jedoch auch im BATCH-Betrieb sinnvoll. Im diesem Fall werden die Auftr~ge durch Steuerungen gegeben~ die mit dem vom Programm ben~tigten Input eingelesen werden. Auf diese Weise k~nnen zum Beispiel w~hrend des Rechenlaufs an vom Benutzer angegebenen Stellen des ALGOL-Programms die Werte von Variablen ausgegeben werden, ohne da2 der Programmierer in sein Programm die entsprechenden Druckanweisungen einfGgen mu2. NatGrlieh sind nicht alle Auftr~ge9 die im Dialogbetrieb bearbeitet werden k~nnen, auch fGr den BATCH-Betrieb sinnvoll, da der gesamte Input des TRACER3 schon bei Beginn des Rechenlaufs festgelegt ist. 3. ~nderun~sma2na hmen i~ ALGOL-System

3.1.

BREAKPOINTS

Um einen kontrollierbaren Programmablauf durchfGhren zu k~nnen, wird vom Compiler vor jedem STATEMENT sine Unterbrechungsm~gliehkeit,

ein

BREAKPOINT, eingebaut. Wenn keine Unterbrechung stattfinden soll, ist der Zeitbedarf fGr das Durchlaufen der BREAKPOINTS gering im Verh~ltnis zur AusfGhrungszeit des Gbrigen Objektprogramms. Daher erfolgt die Erzeugung von BREAKPOINTS dutch den Compiler standardm~2ig, kann jedoch dureh den Programmierer ausgeschaltet werden. Auf diese Weise kann der TRACER jederzeit aktiviert werden, das hei2t, die Entscheidung, da2 der TRACER auf sin ALGOL-Programm angewendet werden soll,

175

kann noch getroffen werden, w~hrend sich das Programm bereits in der AusfGhrungsphase befindet. Es wird jeweils gespeichert, welchen BREAKPOINT das Programm zuletzt durchlaufen hat. Daher kann bei einem Programmabbruch (z.B. wegen Pregrammierfehler oder abgelaufener Rechenzeit) die entsprechende Stelle angegeben werden. Die Identifikation der BREAKPOINTS geschieht durch die Zeilennumerierung des Sourcetextes° Befinden sich in einer Zeile mehrere BREAKPOINTS, so werden sie zus~tzlich pro Zeile fortlaufend numeriert. 3.2. Zusatzinfqrmationen auf Hinter6rundspeicher W~hrend der ProgrammGbersetzung wird vom Compiler die Namensliste erzeugt, die Informatienen Gber die im Sourcetext verwendeten Ns~nen enth~lt. Sie wird normalerweise beim Rechenlauf nicht mehr ben~tigt. Nach Beendigung der Compilierung wird die Namensliste auf einen Hintergrundspeicher geschrieben, damit sie dem TRACER zur VerfGgung steht, wenn er Auftr~ge erh~lt, in denen die Namen aus dem Seurcetext verwendet werden. Auf diese Weise ist es m~glich, be± einem Programmabbruch wegen eines Programmierfehlers oder abgelaufener Rechenzeit s t a n d a r d m ~ i g einen ERROR DUMP auszugeben, der eine vollst~ndige 0bersicht Gber den vom Programm erreichten Zustand bietet. Es werden die Namen und die momentanen Werte aller an der Stelle des Programmabbruchs deklarierten Variablen ausgegeben. 3.3. Verarbeitung v0n spontanen Mitteilun~en Um Eingriffe in einen Programmablauf vornehmen zu k~nnen, ist es erforderlich, Informationen, die aus spontan eingegebenen Mitteilungen stammen, zu verarbeiten. Die dazu notwendigen Voraussetzungen werden vom Betriebssystem der Kieler EL - X8 erfGllt. Es sind Fernschreiber vorhanden, an denen Ein- und Ausgabe vorgenommen werden kann. Als Symbolvorrat steht der Telecode zur VerfGgung. Uber diese Fernschreiber sind jederzeit spontane ~itteilungen m~glich, die an das ALGOL-Subsystem weitergegeben werden k~nnen. Dadurch b e s t e ~ die M~glichkeit, den Programmablauf spontan zu b e e i n f l u s s e n u n d nicht von vornherein endgGltig und unab~nderlich festzulegen. Der TRACER benStigt nur eine einzige spontane Mitteilung, fGr die der Name "TRACE" gew~hlt wurde. Sie bewirkt eine Progrsmmunterbrechung beim n~chsten BREAKPOINT. Auf eine weitere Spezifikation kann bei der

176

spontanen Mitteilung verzichtet werden. Wenn das Programm bei einem BREAKPOINT unterbrochen ist, werden vom TRACER n~here Einzelheiten angefordert. 4. Auf~aben des TRACERS Die Einwirkungen des TRACERS auf ein ALGOL-Programm gliedern sich in drei Abschnitte: I. Unterbrechung des Programmablaufs 2.

e

Analyse und Ab~nderung des bei der Unterbrechung erreichten Zustands Fortsetzung des Programmablaufs

4.1. Pro~rammunt_erbrechun~ Die Programmunterbrechung

kann erfolgen

I.

spontan (d.h. beim n~chsten BREAKPOINT,

2.

bei vorgew~hlten BREAKPOINTS

3.

bei Auftreten eines Programmierfehlers

den das Programm erreicht)

4.2. Analzse un d Ab~uderun ~ des Prq~rammzustandes Bei Eingabe eines Namens (gegebenenfalls mit Indexliste) wird der zugeh6rige Weft ausgegeben. Ebenso kann ein neuer Weft eingegeben werden, der dann der entsprechenden Variablen zugewiesen wird.

4.3. P r o g r a m m f q r t s e t ~ Ein unterbrochenes Programm kann an folgenden Stellen fortgesetzt werden: I. An der Unterbrechungsstelle. einem BREAKPOINT,

(Falls die Unterbrechung nicht bei

sondern dutch einen Programmierfehler

erfolgte,

ist darunter der letzte BREAKPOINT vor Auftreten des Fehlers zu 2.

verstehen). Bei einem LABEL des ALGOL-Programms, wenn dieses mit der Blockstruktur vertr~glich ist, d.h., wenn der LABEL sich in dem Block, in dem das Programm unterbrochen wurde, oder in einem Gbergeord-

3.

neten Block befindet. Bei einem anderen BREAKPOINT, wenn dieses mit der Blockstruktur vertr~glich ±st.

5. Bedienun~ des TRACERS im K±eler ALGqL-S~stem 5.1. Uberblick Gber Sen Dialog ~

F ernschreiber

Die A k t i v i e ~ g des T R A C ~ S geschieht spontan durch Eingabe des Wortes "TRACE" an einem Fernschre±ber. Dadurch wird eine Programmunterbrechung beim n~chsten BREAKPOINT bewirkt. Erfolgt die spontane Mitteilung "TRACE" bereits w~hrend der Compilierung, so geschieht die

177

Programmunterbrechung beim ersten BREAKPOINT des Objektprogramms. Bei Auftreten eines Programmierfehlers erfolgt ein R~cksprung auf den letzten BREAKPOINT vor Auftreten des Fehlers und ansch]/eSend eine Programmunterbrechung. Der TRACER gibt bei unterbrochenem Programm die Zeilennummer und die Nunumer des BREAKPOINTS innerhalb dieser Zeile am Fernschreiber aus. Anschlie~end wird die Eingabe eines Auftrages erwartet. Jeder Auftrag wird vor seiner Ausftthrung vollst~ndig eingelesen und auf seine Richtigkeit dberprNft. Es ist also gewihrleistet, da~ duroh fehlerhafte Auftrige an den TRACER keine Zustandsgnderung des ALGOL-Programms bewirkt werden kann. Bei Eingabe des Symbols "%~RDA" wird die Ausf0/%rung des Objektprogramms fortgesetzt. In allen anderen Fillen muS zunichst der Name eines der Auftrige eingegeben werden, die im folgenden Abschnitt beschrieben werden. Nach der Auftragsausf~hrung ist der TRACER zur Eingabe des n~chsten Auftrags bereit. 5.2. Die T ~ C E R - A u f t r ~ g e

Go To Der Name eines LABELS wird eingelesen und anschlie~end ein Sprung auf die entsprechende Stelle des Objektprogramms ausgefGhrt, falls es mit der Blockstruktur vertr~glich ist. Danach wird vor der Ausf~hrung des n~chsten STATE,gENTS der TRACER erneut aufgerufen, so da~ e~n neuer Auftrag eingegeben werden kann. LINE Es werden Zeilennummer und dle Nummer eines BREAKPOINTS in dieser Zeile, durch Schr~gstrich getrennt, eingelesen. Beim ersten BREAKPOINT in einer Zeile genGgt es, nur die Zeilennummer anzugeben. Wenn es mit der Blockstruktur vertr~glich ist, wird ein Sprung auf den angegebenen BREAKPOINT ausgeftLhrt. Unmittelbar anschlie~end wird der TRACER erneut aufgerufen. STOP ,

j

J

Wird kein weiterer Input gegeben, so ist die Wirkung die gleiche, wie bei der spontanen Mitteilung "TRACE". Das bedeutet, dab das Programm nach Ausft~hrung des n~chsten STATEMENTS erneut unterbrochen wird. Wird ein BREAKPOINT eingegeben, so erfolgt der TRACER-Aufruf nur bei diesem BREAKPOINT. Zus~tzlich kann eine Zahl eingegeben werden, die angibt, wie oft das Objektprogramm diesen BREAKPOINT passieren soll,

178

bevor es den TRACER aufruft.

GO0~ Die Programmunterbrechung bei jedem BREAKPOINT, die durch die spontane Mitteilung "TRACE" oder den Auftrag "STGP" ohne weiteren Input bewirkt wurdep wird wieder aufgehoben. Die Programmunterbrechungen bei speziellen BREAKPOINTS, die durch den Auftrag "STOP" bewirkt wurden, bleiben jedech erhalten. FILL Der Name einer einfachen oder indizierten Variablen vom Typ 'REAL', 'INTEGER' oder 'BOOLEAN' wird eingelesen. Wenn es s i c h u m

eine indi-

zierte Variable handelt, mu~ anschlie~end die Indexliste, bestehend aus ganzen Zahlen mit oder ohne Vorzeichen, folgen. Anschlie2end wird der Wert eingelesen, der der Variablen zugewiesen werden sell.

DUMP Die Hauptaufgabe des TRACERS ist es, Werte von Variablen auszugeben. Nach dem Wort "DUMP" kann ein BREAKPOINT eingegeben werden. Falls eine weitere Zahl eingegeben wird, so gibt diese an, wie oft das Objektprogramm den BREAKPOINT passieren sell, bevor der DUMP ausgegeben wird° Schlie21ich kann noch eine Zahl eingegeben werden, die angibt, nach wieviel Durchl~ufen der DUMP wieder abgesetzt werden sell. Fehlt die Angabe eines BREAKPOINTS, so wird der DUMP sofort ausgegeben. Es kSnnen anschlie~end die Namen von beliebig vielen einfachen oder indizierten Variablen vom Typ ~REAL',

'INTEGER' oder 'BOOLEAN' einge-

geben werden. Dabei dGrfen auch die Namen formaler Parameter verwendet werden. Die Ausgabe von Teilen von ARRAYS ist ebenfalls mSglich. Dazu mu2 nach dem Namen der indizierten Variablen fGr jeden Index zun~chst ein Komma und anschlie2end die Information Gber den gewttuschten Wertebereich eingegeben werden. DafGr gibt es folgende M~glichkeiten: I.

Keine Angabe (in diesem Fall wird der gesamte Bereich ausgegeben)

2. 3.

Ein einzelner Weft Untere und obere Grenze durch Schr~gstrich getrennt.

(Es kann

auch eine der beiden Grenzen fehlen. Sie wird dann durch die aktuelle untere bzw. obere Grenze des ARRAYS ersetzt). Die Werte in der eingegebenen Indexliste k~nnen ganze Zahlen mit oder ohne Vorzeichen oder Namen yon arithmetischen Variablen sein. Die Berechnung der Indexwerte gesehieht unmittelbar vet der Ausgabe des ARRAYS, so da~ bei Verwendung yon Namen in der indexliste die dynamische ~nderung der Grenzen des ARRAY-DUMPS m~glich ist.

179

Falls ein Index au~erhalb des Deklarationsbereichs

liegt, wird der ge-

samte Bereich ausgegeben. CLEAR Wird ein BREAKPOINT eingegeben,

so werden die Auftr~ge,

die durch

"STOP" oder "DUMP" fur diesen speziellen BREAKPOINT erteilt wurden, rUckg~ngig gemacht. Erfolgt kein weiterer Input, so gilt das Entsprechaude fur alle BREAKPOINTS. Teil 2: MEDEA - M_ixed ~ditor and ~±rect ~xecutor of ~LGOL-STATE~TENTS I. Einleitung Ausgangspunkt bei der Konzeption des Dialogsystems MEDEA war der an der EL - X8 implementierte h~rige ALGOL-Runningsystem.

3-Pass BATCH-ALGOL-Compiler

sowie das zuge-

Dutch geeignete Ab~nderungen sollten diese

beiden vorhandenen Programmpakete

einem direkt compilierenden

(l-Pass)

Anschlu~modul zur Verf~gung gestellt werden, welcher folgende Forderungen erfUllen sollte: (I) Generierung von ALGOL-Objektprogrammen

±m Dialogbetrieb;

(2) DurchfGhrung einer umfassenden Fehlerdiagnostik bei Syntaxfehlern; (3) Erhaltung des bereits fehlerfrei erzeugten Objektcodes bei Syntaxfehlern; (4) MGglichkeiten zur Reaktion auf logische Programmierfehler - dazu geh~rt nachtr~gliches Ab~ndern des Objektcodes durch EinfGgen bzw. L~schen von Programmteilen ohne Recompilationsaufwand; (5) AusfUhrung des erzeugten Objektprogrammes bzw. einzelner in sich abgeschlossener Progrsmmteile; (6) Zugriff zur ALGOL-Library; (7) Speicherung des Quellprogrammes auf Hintergrundspeichern teren Verwendung bei sp~teren Dialogsitzungen.

zur wei-

MEDEA zeigt einen Weg auf, wie dieser Forderungskatalog realisiert werden konnte, ohne da~ es n~tig war, einen v~llig neuen Compiler zu entwerfen. Denn der Code-Generator

(Pass 3 des ALGOL-Compilers)

konnte

vom MEDEA-System fast unver~ndert Ubernommen werden, lediglich Pass I und Pass 2, welche vom ALGOL-Compiler zur Verarbeitung der Deklarationen sowie zum Aufbau der Namensliste ben~tigt werden, muBten um- bzw. neugeschrieben werden. Da die Code-Generierung vollkommen ALGOL-konform vorgenommen wird, folgt unmittelbar, dab die yon MEDEA generierten Objektprogramme unter Kontrolle des ALGOL-Runningsystems ausgefdhrt werden k~nnen, ohne da~ an diesem Programmpaket Gberhaupt etwas ge~ndert werden mu~te.

180

Die vorliegende Arbeit will einen Einblick in die Arbeitsweise

des

Dialogsystems MEDEA geben sowie einige Punkte zur Implementierung erl~utern.

Im folgenden 2. Abschnitt wird zun~chst auf die Syntax von

~EDEA-Programmen

eingegangen.

Die Code- und Listenerzeugung,

die nach

Eingabe von Sprachelsmenten wie STATEMENTS und Deklarationen durchgefGhrt wird, soll im 3. Abschnitt behandelt werden.

Schlie~lich be-

sch~ftigt sich der 4. Abschnitt mit Steuerungskommandos,

die dem Be-

nutzer Programmausftthrung, nachtr~gliche Objektprogramm-~anipulationen sowie I-O-Aktivit~ten erm~glichen. 2. Zur S~yntax von ~EDEAspro~ramme ~ Es ist klar, dab der 0bergang vom 3-Pass zum l-Pass Compiler einerseits sowie der in Abschnitt

I aufgefGhrte Forderungskatalog

anderer-

seits zu Einschr~nkungen bzwo Ab~nderungen gegenGber der Syntax von ALGOL 60 ft~hren mGssen. Die globale syntaktische Struktur, ~EDEA-Programm besitzen mu~, l ~ t

die sin

sich in drei Hauptformeln zusammen-

fassen: A) Ein MEDEA-Programm

darf aus nur einem Block (im folgenden Globaler

Block genannt) bestehen.

Der Globale Block kann jedoch sine beliebige

Anzahl v o n Prozedurbl~cken enthalten, Bl~cke besitzen° B) MEDEA akzeptiert Progra~ue,

sofern diese keine inneren

die aus einer Folge yon STATEMENTS und

Deklarationen bestehen. Der Zwang, alle zu benutzenden IDENTIFIERS am Anfang des Globalen Blocks zu deklarieren, ration yon Prozeduren besteht

entf~llt.

Beider

jedoch weiterhin die Vorschrift,

Deklaalle

lokalen Deklarationen am Anfang des PROCEDUREBOD¥S a u s z u f ~ r e n . C) Alle in STATEMENTS benutzten IDENTIFIERS mGssen deklariert bzw. als Library-Namen bekannt sein (Ausna~ne: LABELS in GOTO STATEMENTS). Die Einschr~nkung der ALGOL 60 - Syntax dutch die Forderung A) wird durch B) abgemildert.

Die M~glichkeit

zur Deklaration neuer Variablen

und Prozeduren w~hrend der Programmerstellung ist fGr ein Dialogsystem unerl~lich. beider

Da die Zulassung einer beliebigen Blockverschachtelung

vorhandenen Problemstellung nicht realisierbar erschien, wurde

hier der Weg der parallelen Compilation von STATENENTS und Deklarationen beschritten. Die Syntax yon STATE,gENTS, DECLARATIONS und EXPRESSIONS in MEDEA entspricht bis auf einige Einschr~nkungen der y o n ALGOL 60, wie sis in [I] dokumentiert

ist. Diese Einschr~nkungen

seien hier kurz aufge-

ftthrt: I) Die Deklaration yon SWITCHES und OWN-Variablen ist nicht zugelassen.

181

2) Formale Parameter mGssen be± einer Prozedurdeklaration

spezifi-

ziert werden° 3) DESIGNATIONAL stehen.

EXPRESSIONS

dGrfen lediglich aus einem LABEL be-

4) Der Gebrauch von INTEGER I ~ S Abschnitt 4). 3. Die Code-Generierung

~!.

Prt~rammeinheiten

±st eingeschr~nkt

(siehe dazu

±m D±alo~betr±eb derD±alogsprache

Dieser Abschnitt besch~ftigt sich mit der Eingabe von Sprachelementen wie STATEMENTS und Deklarationen Gber das Terminal. Da ein ALGOLSTATEMENT

±nfolge der zugelassenen

(IF CLAUSE, FOR CLAUSE,

syntaktischen Konstruktionen

COMPOUND STATEXENT)

ein kompliziertes

syntak-

tisches Geb±lde sein kar~u, ±st es nicht sinnvoll, den Dialogpartner des Benutzers erst nach der vollst~hudigen Eingabe eines ALGOLSTATEMENTS wieder zu akt±vieren. Vielmehr wurde bei der Implement±erung von MEDEA Wert darauf gelegt, da~ sich ein XEDEA-Programm in m~glichst kleine, sinnvoll in sich abgeschlossene Programmeinheiten zerlegen lASt. Diese E±nte±lung muS so vorgenommen werden, da~ der Compiler in der Lage ±st, aus e±ner Programmeinheit zu comp±lSeren,

einen sinnvollen Code

der dann auch durch etwaige syntaktische

der E±ngabe weiterer Programmeinheiten darf.

Fehler be±

nicht mehr zerst~rt werden

Diese elementaren Progrannueinheiten bestehen aus:

I)

den AIGOL BASIC STATEMENTS: PROCEDURE - STAT~{ENT

ASSIGNMENT-,

GOTO -, DUXNY - und

;

2)

den ALGOL DELIMITERS BEGIN und END;

3)

dem IF CLAUSE

4) 5) 6)

dem FOR CLAUSE (FOR (VARIABLE) den TYPE Deklarationen; den ARRAY Deklarationen;

7)

dem PROCEDURE HEADING ( PROCEDURE ; < V A L U E PART> <SPECIFICATION

Die Aufteilung

( IF (BOOLEAN EXPRESSION>

in Programmeinheiten

:=

THEN ) ;


DO ) ;

IDENTIFIER> ) .

und die dadureh bedingte zei!en-

slrukturierte Eingabe yon MEDEA-Programmen bringt dem Benutzer den Vorteil, dab er zum ersten bei Syntaxfehlern nur wenige Symbole neu einzugeben hat und zum zweiten versehiedene Steuerungen, die a!s solehe nieht zum Quelltext geh~ren~ an m~gliehst vielen Programmpunkten ausl~sen karm. Naeh der Eingabe einer Programmeir~heit ~ber das Terminal gibt XEDEA O.K.- bzw. Fehlermeldung aus sowie einen dem Programmstatus entspreehenden LEVEL-OUTPUT. Dieser zeigt dem Benutzer an, dab er sieh

182

w~hrend der Programmerstellung I)

im Globalen Block (LEVELOUTPUT: B )

2)

in einer Prozedurdeklaration

3)

( P )

beim nachtr~glichen EinfGgen weiterer STATEMENTS in den Globalen Block ( BG ) oder in sine Prozedur ( PG )

4)

in einem verschachtelten COMPOUND STATEMENT ( z.B. B~,PI,BG2

)

befindet. Der LEVEL-OUTPUT dient zur Entscheidungshilfe, welche Steuerungen erlaubt sind, ob deklariert werden darf u.~., zugleich zeigt er an, da2 die letzte Programmeinheit syntaktisch richtig war und der zugeh~rige Code generiert ist° Bei syntaktischen Fehlern ist der letzte LEVELOUTPUT Merkmal dafGr, da2 bei der Programmerstellung ab hier fortgefahren und die zuletzt und fehlerhaft eingegebene Progr~mmeinheit als nicht existent betrachtet werden kann. 3.2. Compilierun~ der Deklarationen und STATEMENTS In drei Bereichen werden w~hrend der Compilation von MEDEA-Programmen die internen Informationen gespeichert: Im Programm-Array das erzeugte Objektprogramm, in der Namensliste die Namen, der Typ, die Dimension usw. aller Variablen und Prozeduren sowie im Text-Array auf Hintergrundspeicher (Trommel) der eingegebene Quelltext. Der Quelltext ist dabei jederzeit abrufbereit etwa zur Herstellung eines LISTINGS oder zur Kopierung auf Magnetband bzw. Platte fGr eine sp~tere Recompilation, webei das Text-Array so organisiert ist, da2 auch erst z.B. sp~ter eingefGgte STATEMENTS an der "richtigen Position" im Quelltext erschei~ nen. In den folgenden beiden Abschnitten sollen nun einige Erl~uterungen zum Aufbau der beiden anderen Informationsbereiche - ProgrammArray und Namensliste - bei Eingabe von NEDEA-Programmen gegeben werden. 3.2.1. Deklarationen !m Gegensatz zur ALGOL 60-Syntax dttrfen, wie oben schon erw~hnt, die Deklarationen im Globalen Block nach der Compilierung eines STATEMENTS (eine oder mehrere MEDEA-Programmeinheiten) ausgefGhrt werden. Dabei werden in der Namensliste die dem Typ der Variablen entsprechenden Informationen notiert und im Programm-Array die ben~tigten Speieherpl~tze reserviert (statische Adressierung). IDENTIFIERS von TYPE- und Prozedurdeklarationen k~nnen bei der weiteren Programmersteliung so behandelt werden, als w~ren sie in der Deklarationsliste des Globalen Blockes aufgeftthrt. Daraus folgt insbesondere, da2 beim nachtr~glichen EinfGgen von STATEMENTS an Programmstel!en, die statisch vor einer Dekla-

183

ration liegen,

dennoch die erst "sp~ter" deklarierten V a r i a b l e n u n d

Prozeduren benutzt werden dGrfen. Einen Sonderfall bilden hier A ~ A Y Deklarationen.

Um dynamische ARRAY-Deklarationen

Gegensatz zur ALGOL 60-Syntax erlaubt,

zuzulassen,

ist es im

in der BOUND PAIR LIST des

ARRAYS Variable des Globalen Blocks zu benutzen.

Da der ben~tigte

Spei-

cherplatz den ARRAYS erst w~hrend des RUNS zugewiesen wird, gilt fur den Gebrauch von ARRAYS folgende Grundregel: ARRAY-Elemente

dGrfen in

STATEMENTS nur dann verwendet werden, wenn im dynamisehen Programmablauf die ARRAY-Deklaration

und damit die Zuwei~ung des Speicherplatzes

zuvor vollzogen wurde. Bei der Deklaration einer Prozedur wird in der Namensliste

eine spezi-

elle Datenstruktur erzeugt. W~hrend alle Variablen des Globalen Blocks seriell in der Namensliste

abgespeichert werden (serieller Suchproze2),

mu2 dagegen beim Auftreten von IDENTIFIERS in Prozedur-STA~EMENTS sichergestellt werden, len Parameter,

da2 erst die lokalen Variablen,

dann die forma-

dann die globalen Variablen und schlie21ich die Stan-

dardnamen auf Namensgleichheit

durchsucht werden. Dies wird erreicht

durch geeignete POINTER in der Namensliste,

die den Suchproze~ steuern

und die w~hrend der Compilation der Prozedur insbesondere bei LABELDeklarationen dynamisch ge~ndert werden. Die lokalen Variablen der Prozedur werden im Gegensatz zu den globalen Variablen dynamisch adressiert, da Prozeduren rekursiv sein k~nnen. Die zugehSrigen Speicherpl~tze werden w~hrend des RUNS im Keller 3.2.2.

(STACK) zur VerfGgung gestellt.

STATEMENTS ,, ,,

J

Die Compilierung eines ALGOL-STATEMENTS Subroutine des Code-Generators. Bei Aufruf dieser Subroutine I) POINTER zur Namensliste.

erfolgt durch eine rekursive

Die Codeerzeugung erfolgt nach ~2] .

sind folgende Parameter mitzugeben: Dieser ist der Startpunkt des Suchprozes-

ses nach auftretenden IDENTIFIERS,

wobei der Startpunkt unter-

schiedlich ist fttr den Globalen Block und fur Prozeduren. 2) POINTER zum Ende der aktuellen~Namensliste.

Bei etwa auftretender

Deklaration von LABELS k~nnen diese noch in die Namensliste aufgenommen werden. 3) POINTER zum Programm-Array. Code gespeichert.

Ab hier wird der zum STATEMENT geh~rige

4) die For-Tiefe. Diese ist im allgemeinen Null, wird jedoch bei nachtr~glichem EinfGgen von STATENENTS in FOR-STATEmeNTS ungleich Null. Nach Eingabe einer Programmeinheit

ist i.a. der zugeh~rige

Code voll-

st~ndig erzeugt. Besteht jedoch ein ALGOL-STATEMENT aus mehreren MEDEAProgrammeinheiten, so wird in einem weiteren Bereich, dem Compiler-

184

STACK, Information gespeichert, be diesesSTATEMENTS

die erst nach der vollst~ndigen Einga-

(d.h. aller zugeh~rigen Programmeinheiten)

in den

endgt~ltigen Code umgesetzt werden kann. Bei Eingabe von GOTO STATEMENTS auf nicht deklarierte LABELS bleibt der Objektcode zun~chst unvollst~ndig;

er wird bei Deklaration dieser LABELS erg~nzt.

4. Steuerun~en 4.1. Allgemeines Jeweile nach Eingabe einer Programmeinheit

ist es dem Benutzer m~glich,

MEDEA verschiedene Steuerungskommandos anzubieten. MEDEA erkennt Steuerungsanweisungen an einer Eingangsindikati0n (dem Symbol "*", mit welchem keine Programmeinheit beginnen kann) und akzeptiert bzw. verwirft sie in Abh~ngigkeit vom Programmstatus.

Steuerungen,

die zu

jedem Zeitpunkt des Dialogs ausgel~st werden k~nnen, gestatten z.B., das I-O-Medium neu festzulegen,

ein LISTING des aktuellen Quelltextes

auszugeben oder das erzeugte Objektprogramm zu 15schen. Andere Steuerungen, wie z.B. ProgrammausfGhrangskommandos oder die Anweisung zum EinfGgen von STATEMENTS an einem definierten Programmpunkt, sind nur nach Eingabe vollst~ndigerSTATEMENTS oder Deklarationen erlaubt. Im weiteren soll auf die beiden wichtigsten Gruppen der Steuerungskommandos,

die Programmablaufeteuerungen

und die EXECUTE-Steuerungen,

n~her eingegangen werden. Als Parameter k~nnen diesen Steuerungen INTEGER LABELS mitgegeben werden, welche gem~2 ALGOL 60-Syntax vor jedem STATEMENT deklariert werden dGrfenund, falls sie als Steuerungsparameter verwendet werden~ auch deklariert sein mGssen. Bei der Deklaration eines INTEGER LABELS werden im Programm-Array

drei Pl~tze reser-

viert, auf denen diese Steuerungen operieren, 4.2. P r o g r a m m a b l a u f s t e u e r u n ~ 4.2.1. Die S t e u e r u n ~ I N T E G E R

LABEL~_

Die diesem Kommando folgenden STATEMENTS werden in das Objektprogramm eingefGgt und zwar unmittelbar vor dem und auf demselben Niveau (ForTiefe, Compomnd-~_efe) des angegebenen INTEGER LABELS. Beendet wird dieser Proze2 durch eine andere Steuerung (z.B. dureh die Dummy-Steuerung *GOON). Beispiel:

185

Vorher

Steuerung

Nachher FOR CLAUSE

FOR CLAUSE

*GOON ]

BEGIN

STATEMENT k

BEGIN STATEMENT I

m

STATEMENT ]

I

STATEMENT k

I

I

I: STATEMENT 2

STATEMENT n

I

END

*GOON

!

STATE~IENT n I: STATEMENT 2 END

Dieser Steuerungsmechanismus ist komfortabel in dem Sinne, da2 das Einftigen weiterer Programmteile beliebig oft bei demselben INTEGER LABEL vorgenommen werden darf und es erlaubt ist, auch in z.B. schon vollst~ndig deklarierte Prozeduren oder in Programmteile, die ihrerseits erst selbst nachtr~glich hinzugef~gt wurden, weitere STATEMENTS einzufGgen. Die Compilierung und Syntaxprtifung eines solchen STATEMENTS gelingt durch richtiges Setzen der in 3.2.2. erw~hnten Parameter bei Aufruf des Code-Generators, wobe± die Parameter aus Informationen, die diesem INTEGER LABEL in der Namensliste zugeorduet sind, erzeugt werden kSnnen° Im Programm-Array wird der aus den eingefGgten STATE~NTS

compilierte Code hinter dem gerade aktuellen Objektprogramm ab-

gespeichert. Durch mehrere Sprungbefehle wird der richtige Programmablauf sichergestellt. Dieses Verfahren erm~glicht es, da2 an beliebigen Programmpunkten beliebig oft und beliebig viele STATEMENTS r~chtr~glich eingefGgt werden kSnnen, sofern der Benutzer mit der Deklaration von INTEGER LABELS nicht gespart hat. Um Eindeutigkeit der INTEGER LABELS zu erzwingen, ist es im Gegensatz zu anderen ZABELS nicht gestattet, denselben INTEGER LABEL sowohl im Globalen Block als auch in Prozeduren zu deklarieren. Die Steuerung *GOON arbeitet auf den ersten beiden der drei Zellen, die im Objektprogramm pro INTEGER LABEL reserviert sind. In die erste wird der Aussprung aus dem bisherigen Programmablauf eingetragen, die zweite enth~lt die R~cksprungadresse aus der letzten GOON-Schleife. Diese Adresse wird bei der Generierung einer weiteren G00N-Schleife bei diesem LABEL ben~tigt. Die Struktur des Objektprogramms nach zwei GOON-Steuerungen bezGglich eines INTEGER LABELS sieht wie folgt aus:

186

~] O b ~ektprogramm, normaler Programmablauf

I GOTO(:X) :Z

INTEGER LABEL

GQ~o(:D)~ ~

C: D:

~ Dritte Zelle: siehe 4.2.3.

~

Objektprogramm, normaler Programmablauf

,,,GOTO(:A ) X:~ ~

I 1I

AJ~I ~I ,,,~,,,,,',

} Objektprogramm, erste GOON-Schleife

I ObjektprOgramm' n°rmaler PrOgrammablauf

~

,}

Objektprogramm,zweite GOON-Schleife

z, I GOTO(: m

B: I

~

I

:X bedeutet: Adresse des Speicherplatzes X

4.2.2. Die Steuerun~en A) *DELETE ~....BI*DELETE
cl *DELETe- ~INTEGER LAB~_~. Diese Steuerungen dienen zum L~schen von Programmteilen. A) l~scht das gesamte Objektprogramm, B) das Objektprogramm beginnend und mit Einschlu~ des angef~rten INTEGER LABELS. Die Steuerung C) entfernt das dem INTEGER LABEL folgende ALGOL BASIC STATEMENT, der LABEL selbst bleibt erhalten. Im Gegensatz zu A) und B) wird bei C) dem Dialogsystem der gel~schte Speicherraum nicht wieder zur VerfGgung gestellt. 4.2.3. Die Steuerung *GOTO ~INTEGER LABEL I~T
A) macht die letzte Steuerung *GOON bez~glich des angesprochenen

187

INTEGER LABELS rt~ckg~ngig,

B) entsprechend die Steuerung *GOTO.

4.3. EXECUTE-Steuerun~en Die AusftLhrung des gesamten bzw. eines Teiles des Objektprogrammes wird durch die Kommandos *DO, *DO , *DO , erreicht, wobei I) das gesamte Programm, 2) das Programm ab INTEGER LABEL1 u~d 3) das Programm von INTEGER LABELI bis INTEGER LABEL2 durchlaufen wird. Es ist also m~glich, mehrere in sich abgeschlossene MEDEA-Programme, die Gber Globale Variable (aber nicht ARRAYS) miteinander korrespondieren und gemeinsame Prozeduren benutzen k~nnen, abzuspeichern und getrennt aufzurufen.

~rch

Zugriff zur ALGOL-Library ist w~hrsnd des RUNS sichergestellt, da2 MEDEA-Programme eine Vielzahl von Rechenprozeduren benutzen sowie die gesamte Peripherie der EL - X8 ansprechen k~nnen. Nach Beendigung des RUNS kann der Benutzer mit der Programmerstellung bzw. -Ab~nderung fortfahren, einen weiteren RUN starten oder den Quelltext fur eine sp~tere Dialogsitztmg auf Hintergrundspeicher retten. EingriffsmGglichkeiten

in den Programmablauf w~hrend des RUNS sind von

MEDEA her (noch) nicht realisiert,

aber vorgesehen.

Lediglich durch

spontane Mitteilungen an das Betriebssystem kann ein laufendes MEDEAProgramm abgebrochen werden. Die Kontrolle geht dann vom ALGOL-Rur~uingsystem an das Dialogsystem zurGck. 5~ Beispiel einer Dialo~sitzun~; summe v o n N reellen Zahlen Anmerkung:

Be rechnun~ der Wurzel aus der Quadrat-

Der OUTPUT von MEDEA ist unterstrichen.

B B

'INTEGER' I,N; I :READ(I ,N) ;

B

'REAL' SUNNAND, RESULT;

B

2: 'FOR' I:=I 'BEGIN ' B1 3 :RESULT :=~;

KO~ENTAR '' Eingabe yon Channel I '' Terminal

'STEP'I'UNTIL'N'DO'

B_! 4 :READ( I, SUMAND) ; ***ERROR 2~4

99

+I

S~AND

NAME NICHT BEKANNT

B_! 4 :READ( I, SUM~AND) ; B1 5 :RESULT: =RESULT+SUNB~AND*SUMMAND; BI 'END'; B B B

6:WRITE(I,''RESULT= ''); 7:PRINT(I,SQRT(RESULT)) *DO

'' Syntaxfehler:Fehlernummer, '' letztes Symbol,letzte Zahl, '' letzter Name. ''READ,WRITE,PRINT und ''SQRT sind ALGOL-Library''Prozeduren. ''Programmausftthrung

188

''Input-Anforderung 2,2.5,3 RESULT= +3

''N und zweimal SUNMAND '' Logischer Fehler

DONE B

*DELETE -3

''L~sche ein STATEMENT

B

*GOON 2

B_GGI~:RESUL~:=~;

''FGge ein oder mehrere ''STATEMENTS bei LABEL 2 ein.

BG *LIST

''Erstelle LISTING

'INTEGER' I,N; I :READ( I ,N) i, 'REAL' SUNNAND~RESULT~ I~:RESULT:=~; 2:'FOR'I:=I 'STEP'I'UNTIL'N'DO' 'BEGIN' 3:1 4:READ(I,SUN~ND);

5 :RESULT:=R,ESULT+Str~A~*SUM,~NDL "END ';

6:WRItE(t, ,''RESULT= '')i :PRCNT (I ,SQR~ (RESUL~ 1)i B

''Erneute ProgrammausfGhrung

*DO

2,2.5,3 RESULT= '+.39~51248379551¢+¢~I

DONE B REFERENZEN [I] Backus, J.W., et al.: Revised Report

on the Algorithmic Language

ALGOL 60 - Communications of the ACM ~ (1963), Computer Journal [2] REFERENCE MANUAL EL~X8: ALGOL-Compiler, [3] Sch~nerstedt,

ELD 084 HD 116/1968

H.-J.: Ein Multiprogramming-Monitsr

als Kern eines

Batch-Timesharing-Betriebssystems fGr den Rechnerverband EL X8-XI, Diplomarbeit am Rechenzentrum der Universit~t Kiel, 1970 Anschrift der Verfasser: Dipl.-Math. JGrgen Baginski, Institut ft[r Informatik und Praktische Mathematik der Christian-Albrechts-Universit~ 23 Kiel, Olshausenstr.

40-60

Dipl.-Math. Horst Seiffert, dto.

SOME

CHARACTERISTICS

OF

RTL/2

AND

THEIR

REI~VANCE TO PROCESS CONTROL

J.GoP.

BARNES

Introduction RTL/2

is a high-level

the

Corporate

use

in

industrial

involve

real-time

programming

Laboratory and

of

research

data

language

Imperial

developed

Chemical

computing,

acquisition

and

by

a team

Industries

and

particularly

control.

led

Ltd.

by

It

for

the

author

is in%ended

applications

Structurally

a simple

at for

which

language,

it

incorporates features important for the effective programming of real-time applications including the ability %o program tasks which the computer performs in parallel (or at least appears to do so as far as an outside observer is concerned). It was considered particularly important to be able %o produce programs of high integrity which are nevertheless efficient enough in speed and storage requirements to run on small on-llne computers.

This

work

had

a Ferranti laboratory

stages stage.

origin 400

in 1969 control

and

the

The

As

and

similar

has

to the

development

been

on-line

use

described of

a more

RTL/I

successful

the

development This

was

a consequence

to develop

language

plants

in the

in 1967.

processes.

initiated process

its

Argus

by

Law

final

and

of

general

SML

is)

experience language

by

Moloney

used with

and This

Barnes

to program

language,

(a simple

still

applications.

described of RTL/I

of (and

[2];

of Algol)

for

control

SML

the

a formal

related work

[I] was the

variant

was

the

control experience

basic

of two

project software

undertaken

result

of IC[

derived

for of

in

the

first

production from

this

RTL/2.

This paper contains a brief general outline of RTL/2 and then describes some features in more detail with particular emphasis on %heir use in small on-line computers such as are used for process control.

was for

led

1 90

Design The

of RTL/2

following

were

the

main

criteria

for

Conventional

efficient

high-level

Dynamic

creation,

synchronisation

task

Subroutines It should

should be

suitable

as application No

The

should The

by

language

Programs

and

so that

the writing

timing

problems

a conventional itself

be able

notation

for

design

of

termination

multitask

of

RTL/2:

features

large

should

be

available.

should

be

facilitated.

programming

parts

is simplified.

of operating

systems

as well

programs.

unpredictable

controlled

be re-entrant

the

algorithmic

should

to interface should

should

be

be

should

garbage be

independent

with

and

the

(as

might

of particular

existing

straightforward

secure

arise

happen

with

storage

collector).

and

language

operating

systems

and

systems. easy should

to

type

on

encourage

standard the

early

equipment. detection

of

errors at compile time and enable efficient monitoring at run time.

The object code should be efficient in space and not call for extensive run time control routines. The lan&~/age should encourage precise and tidy program management.

The language should be as simple and familiar as possible within the above constraints so that training problems are minimised. Some of these criteria are similar to those for RTL/I {reference I).

Experience

with RTL/I indicated that changes were necessary and it is worth emphasising the more significant ones: It was considered important to keep the language separate from the operating system since system requirements are likely to change rapidly in the near future and we did not wish to build in unnecessary obsolescence. The tendency to use smaller computers despite the fall in hardware costs has increased the emphasis on compact code. A greater concern with human interfaces has led to increased emphasis on areas such as ease of typing, program management and program security.

191

Overall Structure The RTL/2 unit of compilation is ~ne module which is a collection of items known as bricks together with cross reference information required by the compiler. Bricks are of three types:

Procedure

brick:

This It may

restricted

to be and

local

This

scalars

(and

of

directly

of

and

not

coding

local

local

describing

variables

structures

access

or parameters

internal

brick:

parameters

may

variables

include

piece

have

implementation

of a procedure

Data

is a read-only

process.

mechanism

procedures, stacks a n d data bricks.

such

variables

variables

of another

an executable

but

the

latter

as arrays). is re-entrant.

in a data

entry

The

brick,

procedure.

are

The

but

A procedure

coding

not

the

may

not

procedures.

is a named

global

static

collection

of

scalars,

arrays

and

records.

Stack brick:

This is an area used as workspace by a task for the storage of local

variables, links and other housekeeping items such as the seratchpad.

RTL/2

thus

being

the

has

dynamic

scalars

re-entrancy

storage

(and

required

structured

in most

language.

language

since

and

cases

each

the

active

the

simplest

local

By making

is clarified

simplified

of

parameters)

without the

the

stack

description task

kind

with

the

to procedures. costs

quite and

imposed

explicit

control

is uniquely

only

This

dynamic

gives

by

the

a fully

nature

with

block

of the

of multi-tasking

associated

variables

the

greatly

a stack.

Cross References Cross referencing between modules (for compilation purposes) is at the level of bricks.

Any brick

may be specified as an entry and will then be accessible from

within another module.

Conversely in order to access a brick in another module an

external description of that brick must be provided.

There not

are

also

actually

supervisor and

the

SVC

which

may

Data

Types

RTL/2

the

completely

written provide

DATA

brick

which

therefore

for it)

iii) and

types

iv)

the the

in RTL/2.

These

of numerical

FRAC, REAL,

handling an

integer

a fraction a normal

can are

link

to a task,

in a re-entrant

INT,

which

a communication

character the

of bricks

is private

be used

four

integer

machine,

classes

which

integers,

arithmetic

special

call)

provides

unsigned small

two

the

SVC

between housekept

via

PROC

RTL/2

brick

but

(or

the

user

and

supervisor

on

task

changes

and

manner.

data. and

be accessed

These the

or bit in the floating

are

machine pattern

range point

-i

i) the

BYTE,

independent

an

8 bit

manipulation

occupying

the

normal

to +I for

use

in fixed

number.

of

word

of

point

t92

T h e r e are also t h r e e types of control data.

These are i) the LABEL, w h o s e v a l u e

defines an a d d r e s s in a p i e c e of code a n d a l s o an a c t i v a t i o n of that code, it) the PROC, a pointer to a p r o c e d u r e b r i c k and iii) the STACK,

There are two kinds of c o m p o u n d structures,

a pointer to a stack brick.

arrays and records.

indexable set of components of the same type,

An array is an

the lower b o u n d is fixed (at i) - this

allows for efficient array p a r a m e t e r passing.

A record is a group of items of

different types g a t h e r e d t o g e t h e r for ease of reference. RTL/2

also

includes

structures

The

such

parameter

parameter value the

well

variables.

and

is as

queues,

the an

corresponding

These

and

simple

for

one

expression

formal

of

and

useful

indirect

building

is

each

assigned

behaves

as

up new

generally.

in which

value

which

for

addressing

assignment the

parameter

are

actual

as

the

a local

initial

variable

of

procedure.

Executable As

lists

evaluated

the

called

as

mechanism

is

of

reference

Statements as

the

normal

operations

to

enable

for

is

defined.

arrays

aritI~etie the

operations,

efficient

RTL/2

manipulation

includes

of

bit

logical

and

patterns.

shift

A L~GTH

Control statements include assignments, p r o g r a m control (GOTO, SWITCH),

operator

conditional

(IF), r e p e t i t i o n (TO, FOR, WHILE) etc. It should b e n o t e d that a G O T O statement may not only t a k e a literal label as its d e s t i n a t i o n in the u s u a l w ~ y but m a y also b e a p p l i e d to a label variable. latter case s u c c e s s i v e e x i s t i n g p r o c e d u r e calls are

'unwound' until the level

c o r r e s p o n d i n g to the v a l u e of the label v a r i a b l e is found. to the a c t u a l label.

In this

Control is then p a s s e d

This m e c h a n i s m permits efficient e r r o r r e c o v e r y w h i c h

imposes no o v e r h e a d u n t i l r e c o v e r y is necessary. Procedure

variables

parameter

list

call for

is

in

as the

performed;

single

well

this

character

as

usual

literal

way.

procedures

In the

technique

former

is used

may case

widely

in

be

called

this the

by

means basic

appending

that

an

input-output

a

indirect package

streaming.

Input-Output The

RTL/2

since

to

in order package

language

as

do

so might

to

aid

for

such prove

contains an

transportability

character

streaming

no

specific

undesirable of has

burden

programs been

provision for

between

defined.

for

very

small

systems The

input

kernel

an SVC databrick c o n t a i n i n g two p r o c e d u r e variables thus~

and

output

systems.

However,

a recommended of

the

standard

standard

is

1 93

DATA RRSIO; PROC( BYTE)IN; PROC(BYTE) OUT; ENDDATA; The

procedure

input

stream

character

and

procedures

of

to

The

of text

and

and

package

the

via

is very

user;

but

could

The

procedure

easily

be

of various

as

should an

will

the

send

All

by

assigning

Switching that

current

the

streaming

of

different

can

a stream

of procedures

These may

from

be

literal

carried

need

not

out

by

correspond

array.

a variety

types.

out

noted

internal

re-entrant

in OUT stream.

OUT.

be

character

appropriate.

carried IN and

it

next

output

IN or OUT

includes

completely

the

current

variables

the

remove

result.

be

also

numbers

being

will

to

procedure

device

standard

RTL/2

will

or by

to a physical

it as

streams

the

supervisor

called,

as parameter

characters

switching

the

when

return

passed

individual The

in IN,

procedures

be

used

for are

the

input

and

written

entirely

by

tasks

concurrently

all

output in in a

system.

The

re-entrancy

compact To

of

system

illustrate

given

the

whilst the

below.

package

and

offering

simplicity

TWRT

of

outputs

the

ease

convenient the

of

package

a string

stream

switching

facilities the

(an array

text

make

to

the

user

of

two

of the

of bytes)

and

possible

a very

tasks.

IWRT

procedures outputs

is

an

integer

unformatted. PROC TWRT(REF ARRAY BYTE X); FOR I .= I TO LENGTH X DO OUT(X(I)) ~DPROC;

REP;

PROC

IWRT(IN~r N) ; IF N < 0 THEN OUT( '-'); N := -N I~D; IF N > -- 10 THEN IWRT(N:/10) END; OUT(BYTE(N MOD I0 + '0')); ENDPROC; Typical

calls

of these

]~VRT("VALUE

procedures OF

P IS

might

");

be

IWRT(P);

Characl;e_r Set In order

to increase

approach

to the

representation

specific

subset

of

items.

T~us

human

eye

readable being

space

and and

the

ISO7

because as

of

and

full

characters

keywords

ineligible

portability

are the

user

use

are

merely

number

and RTL/2

legibility text

has

of layout

significant reserved

of

identifiers.

keywords

of been

programs It

characters

is made

since

are

identifiers. is

RTL/2 taken.

small

they

This little

a simple

is typed in

delineating

significant makes

problem

in a

to

programs is had

the very

with

them

194

Strings (enclosed in a pair of

") and comments (enclosed in a pair of %) must not

extend over more than one line.

This rule avoids the difficulties familiar to

Algol and PL/I users when a string or comment terminator is inadvertently omitted. Long strings are catered for by the rule that strings which are adjacent, apart from layout characters, The c h a r a e t e r ~ i s

are treated as one.

used to delimit sequences of numbers inserted into strings to

denote non-printable characters.

This technique is particularly useful when

dealing with layout characters or unusual control characters on visual displays, operator

control panels etc.

As a simple example the statement TWRT ("We 10 ~ A C T O R ~

11 #TE~E~#~

I~

P~SSURE ~ ~ 0 ~ ") ;

would output the newline character (code I0), the letters REACTOR, tab character (code II), T E ~ P E ~ T U R E ,

the horizontal

another tab, PRESSURE, and finally a further

newline, RTL/2 has a simple replacement facility whereby these code numbers can be given names thus

LET LET

NL = TAB

=

10; II;

the above example then becomes more legible

TWRT ('~NL~REACTOR~cTAB~/~TE1V~PERATURE#:TAB~t~ P R E S S U I ~ N L g " ); Tasking RTL/2 does not contain specific built in real time statements; primitive facilities with which such statements can be created.

rather it contains Experience with

systems written in RTL/2 has not as yet led to a definite set of primitives which could be considered a standard.

(This contrasts with the input-output case where

a standard has in fact been superimposed on a similar basic philosophy.)

However,

it is possible to describe the usual relationships between bricks in a multitasking system and some of the supervisor procedures which could be available in a system of moderate size. Whenever a new task is created a stack will be nominated as workspaee and a procedure as the coding to be obeyed.

This could be done via a procedure with

external specification SVC PROC(STACK,

PROC(),

INT) MAKETASK

via a call such as MAKETASK(S,P,9); where S is the identifier of a particular stack brick, P is the identifier of the parameterless procedure which denotes the actions t o be performed and the integer is the initial priority.

P can of course call other procedures in the course of

195

its action and access variables in various data bricks as required.

Later operations on the task may then be made by reference to the stack thus STOP(S);

or RESTART(S);

or KILL(S)

Use of STACK variables ensures that the parameter passed to the supervisor is always valid and does not need checking.

An alternative approach is to use an integer to

denote a task (perhaps returned as result of ~[AKETASK) but checks are then necessary to ensure that when the integer is later used as a parameter (of STOP say) it does in fact denote an existing task.

E r r o r Recovery The provision of well org~anised error recovery mechanisms is an important aspect of the design of on-line systems. has emerged;

In the course of the use of RTL/2 a simple standard

it has been deliberately kept simple so that it is viable on very

small systems and more elaborate mechanisms are built around it on larger systems.

Two types of error are distinguished - unrecoverable and recoverable errors.

An

unrecoverable error is one such that further processing of the task concerned might destroy the s t r u c t u r e stack overflow.)

of the system.

(Examples include array bound violations and

A recoverable error is one such that further processing of the

task can continue without danger to the structure of the system.

The kernel of the standard is a n SVC databrick thus DATA RRERR; L A B E L ERL: INTERN; PROC(IN~) ERP; ENDDATA;

ERL contains the unrecoverable error label, ERN the unrecoverable error number and ERP the recoverable error procedure.

On detection of

an unrecoverable error by the system, an appropriate error number is

assigned to E~N, any monitoring facilities invoked and control then passed to the label in ER~.

A user task could simulate an unrecoverable error by merely

assigning a number to ERN and passing control to EEL.

However, this could bypass

the monitoring facilities and so the standard includes PROC RRGEL(INT N) which when called assigns N to E~N, invokes the monitoring and finally transfers control to ERL.

Detection of a recoverable error results in a call of the procedure contained in ERP with the integer p a r a m e t e r

indicating the cause of the error.

errors may be signalled by the system or the user.

Recoverable

1 96

It should be noted that the recoverable error mechanism is less fundamental than the unrecoverable one;

it merely provides a convenient private postbox for

communication between the user and system. A task can create its own error recovery environment merely by directly assi&~ning appropriate values to ERL, ERN and ERP. own error environment,

A procedure which wishes to set up its

whilst preserving the existing one, may do this by assigning

the existing values of ERL, EP~" and ERP to local variables on entry and restoring them on exit.

Elaborate and flexible mechanisms can easily be created when

necessary but little overhead is imposed on simple tasks for which it is unnecessary. Fixed Fixed ware

Point

Arithmetic

point

arithmetic

is

not

available

point software.

is and

often time

used and

in process space

computers

restrictions

when

prevent

floating the

point

use

of

hard-

floating

One approach is to use integers with suitable scaling applied.

Thus suppose we wish to store a temperature which may be up to 1000°C.

In a ~6 bit

machine (maximum integer 32767) this could be done with reasonable accuracy by letting 32 units represent one degree. fractions.

A more satisfactory approach is to use

In this example one degree would be represented by 0.00~.

The most important advantage of the use of fractions is that a knowledge of the word length of the machine is not necessary for the determination of scaling factors.

Fractions are thus of great value in machine independent packages.

change of word length only changes the accuracy of the calculation;

A

no changes in

the overflow conditions arise. The treatment of integers and fractions in RTL/2 is somewhat unusual in that the double length forms occurring naturally in some operations are explicitly defined. This approach makes the language somewhat elaborate but avoids the lack of clarity often encountered with simpler approaches.

The main features will now be outlined.

In addition to the normal single length forms of integers and fractions,

double

length forms are defined which only exist as intermediate results in expressions and cannot be stored in -variables. pictorially in figure i.

These double length forms are explained

The big integer and fine fraction are conventional

double length forms whereas the fine integer and big fraction are both represented by the same mixed form. The

monadic

and

the

do not consider

operator

operator result the

FRAC in

any

current

INT

applied

converts code mixed

being form

to a big a fine

generated in

the

fraction

integer but other

to

converts a big

essentially way.

it

to

fraction. tell

a fine These

the

compiler

integer operations to

197

sign big

fine

integer integer

fraction

normal fine

fraction

~

~

•

F - - - - - - - - ~ o ~

E]

['i.......

fraction

Io l

to

the

~' I

• I I.

operator

according

........

o I

D

multiplication

form

I o

[]

figure

The

point

integer

normal

big

binary

* takes

modes

INT INT FRAC FRAC

forms

of

* * * *

of

two

the

. '"

integers

normal

I

and

forms

i

i

~J

fractions.

and

produces

a double

length

operands

INT --~ FRAC-~ INT -~ FRAC --~

big INT big FRAC big FRAC fine FRAC

Note that multiplication is commutative but that there is a lack of symmetry in that we have chosen the result of multiplying an integer by a fraction to be thought of as a big fraction and not a fine integer.

Division

is

according

the

inverse

to whether

of multiplication

the

desired

but

result

is

here

to

be

we an

have

different

integer

or

operators

a fraction

(:/

and

//respectively). big INT fine INT big F R A C

:/ INT ~ INT :/ F R A C ~ INT :/ FRAC---~ INT

fine big fine

// INT ---@ // INT ~ // FRAC---@

and

Arithmetic The

shift

operators

integers

or

appropriate

INT FRAC FRAC

operators

SLA

(shift

fractions. double

normal

integer

length

form

or

(big

left)

length

left

binary

and

If the

fraction for

enable

SRA

first

FRAC FRAC FRAC

scaling (shift

operand

shift

is

immediately

then

it

will

shift

and

fine

operations

right) is

may

to be be

already

applied.

first

be

for

right

applied

double If,

converted

performed

to

shift).

to

length however, the

The

simply.

either then it

the is

a

appropriate second

double

operand,

of

course, indicates the number of places of shift.

Finally,

it

specific

forms

should

be

remarked

automatic big (

that

transfers

where will

) normal ~

operators be

applied > fine

require if

possible

their thus

operands

to

be

in

1 98

Implementation RTL/2 has been implemented DEC PDP-II. end';

for the ICL System 4, the IBM System 360/370 and the

The compilers are written entirely in RTL/2 and have a common 'front-

the creation of new 'back-ends'

for other machines is relatively

straight-

forward. Standard packages

(mostly written in RTL/2) allow programs to be executed under the

J or OS operating systems on the System 4 and 360/370 respectively. are used for program development and off-line cross-compilation

These systems

for the pDP-II.

A family of operating systems is being written in RTL/2 for the PDP-I1 and the simpler members of this family are currently

in use on several on-line systems in

ICI.

Acknow!eagem.~n~ The a u t h o r

wishes

to acknowledge the efforts

and i m p l e m e n t i n g RTL/2. Corporation,

Central

Limited as well as

o f t h e RTL P r o j e c t

~his team has included

Electricity Imperial

Research

staff

Laborutory

Chemical Industries

Team i n d e f i n i n g

from B r i t i s h

Steel

and International

Computers

Limited.

References I. Barnes, J G P:

Real-time

Vol 15, pp I 5 - I 7 ,

Languages

Third IFAC Conference,

Computer Control of a Multitrain Batch Plant,

Helsinki,

1971.

Mr John G P Barnes, Imperial Chemical

Industries Limited,

Corporate Laboratory, %%~itchureh Hill, Reading,

Computer Journal,

1972.

2. Law, W M, and Moloney, T:

Author:

for Process Control.

Berks.,

U.K.

Bozedown House,

PROZESSORIENTIERTE PROGRAMMIERSPRACHEN FORMEN UND FUNKTIONEN KOCH, G., KUSSL, V.

i.

D!e S t e l l u n g

prozeSorientierter

Programmiersprachen

1.1, Programmiersprachenklassen, Obersicht Auch f u r die Anwendung der ProzeBrechner i s t scheidender Bedeutung.

die Programmierung von ent-

Einen ProzeBrechner programmieren h e i s t a) die p r o z e ~ s p e z i f i s c h e n Anwenderprogramme e r s t e l l e n , und b) das Betriebssystem generieren oder modular zusammensetzen. Untersuchen w i r zun~chst, wie w e i t sich die bestehenden Programmiersprachen zur Programmierung der Proze~rechner eignen. Die heutigen Programmiersprachen (Bild I): Stufe

k~nnen w i r wie f o l g t

klassifizieren

1: Maschinensprachen (Maschinencode MC). I d e n t i s c h sprache a l l e r weiteren Stufen.

mit der Z i e l -

Stufe 2: Assembler-Sprachen und Makro-Assembler. Durch EinfUhrung symb o l i s c h e r Adressen wird die Programmierung gegenUber den Maschinensprachen e r l e i c h t e r t . Die Sprachen der n~chsten beiden Stufen sind durch mathematische Sprachund Programmelemente gekennzeichnet. Z u s ~ t z l i c h kann der Programmierer Prozeduren benutzen ( p r o z e d u r o r i e n t i e r t e Sprachen). Der Programmierer, der Sprachen d i e s e r Klassen b e n u t z t , i s t weitgehend von R o u t i n e a r b e i t b e f r e i t . Im Programm i s t Aufgabenstellung und Aufgabenl~sung anschau!ich formuliert. Diese Sprachen werden p r o b l e m o r i e n t i e r t e chen genannt ( 2 ) .

oder a n w e n d e r o r i e n t i e r t e

Spra-

Stufe 3: Sprachen vom Typus FORTRAN und ALGOL 60. Der v o l l ausgebaute a r i t h m e t i s c h e S p r a c h t e i l i s t ein Kennzeichen dieser Sprachf a m i l i e . Es f e h l t jedoch die K e t t e n v e r a r b e i t u n g und die Verarbeitung yon A d r e s s - V a r i a b l e n . Stufe 4: Sprachen vom Typus PL/I und ALGOL 68. Spraohen y o n diesem Typus erlauben eine voile Ausnutzung

der

200

Bild

I

w

0%

i

L e

i

s t

u n g

100%

\ 100%

100%

~P 4~

4~

.Q .Q

0

0%

0%

0%

G~n

gi

gkei

t J

Klassifizierung

der

Pr0grammiersprachen

100%

201

heutigen D a t e n v e r a r b e i t u n g s a n l a g e n : Z a h l e n v e r a r b e i t u n g , K e t t e n verarbeitung;

gesteuerte Speicherplatzverwaltung, Verarbeitung

von A d r e s s - V a r i a b l e n ;

Bearbeitung von D a t e i e n , Datenmengen

nen a l s Bereiche oder S t r u k t u r e n Die

K r i t e r i e n

(Bild

I):

a) L e i s t u n g

organisiert

kSn-

werden.

zur B e u r t e i l u n g e i n e r Programmiersprache s i n d

(Sprachumfang),

b) Handhabbarkeit ( G ~ n g i g k e i t ) , c) V e r b r e i t u n g , d) A b h ~ n g i g k e i t Eine v o l l e

(Portabilit~t).

L e i s t u n g

erlauben Maschinensprachen

(Stufe

I),

Assemblersprachen ( S t u f e 2) und Programmiersprachen der F a m i l i e PL/I und ALGOL 68 ( S t u f e 4).

Die S p r a c h l e i s t u n g von FORTRAN und ALGOL 60 i s t

dagegen s t a r k e i n g e s c h r ~ n k t . Die

H a n d h a b b a r k e i t

dere V e r t e i l u n g :

(G~ngigkeit)

z e i g t jedoch eine an-

am schwersten zu handhaben sind Maschinensprachen, ~hr

f o l g e n die Assembler-Sprachen. G l e i c h g u t zu handhaben sind a l l e

Sprachen

der Stufe 3 und 4. Unter Handhabbarkeit s o l l

und

hier Erlernbarkeit

A n s c h a u l i c h k e i t verstanden werden ( G ~ n g i g k e i t ) . V~llig

anders i s t

die

V e ~ b r e i t u n g

verteilt.

FORTRAN w i r d PL/I oder gar ALGOL 68 nur wenig b e n u t z t . V e r b r e i t u n g e i n e r Sprache s o l l t e hinderlich Die

A b h ~ n g i g k e i t ebenfal!s

eines Programms von F a b r i k a t und Typus ein w i c h t i g e s

te m ~ g l i c h s t wenig von F a b r i k a t

und P L / I ) bar,

Kriterium.

falls

Ein Programm s o l l -

und Typ eines Rechensystems abh~ngig

Assemblersprachen und Maschinensprachen

jeweiligen

Die d e r z e i t i g e

die z u k U n f t i g e Anwendung n i c h t

sein.

eines Rechners i s t sein.

fur

GegenUber

(Stufe

Iund

2) sind vom

Rechner abh~ngig, Sprachen der Stufe 3 und 4 (FORTRAN, ALGOL sind es n i c h t .

Programm und Rechner sind jedoch nur austausch-

entsprechende Programmiersysteme ( C o m p i l e r usw.) e x i s t i e r e n .

Da Assemblersprachen abh~ngig von F a b r i k a t und Typ eines ProzeBrechners s i n d , w o l l e n w i r deshalb nur Sprachen der Stufe 3 und 4 b e t r a c h t e n . Sprachen d i e s e r S p r a c h f a m i l i e (FORTRAN, ALGOL und P L / I )

Alle

sind jedoch zur

Proze~automatis~erung n i c h t

ausreichend,

schehens, jedoch n i c h t Z e i t statten.

und Ort der Aktionen zu beschreiben ge-

da s i e nur d~e A r t des Ge-

20 2

1,2, ~rogrammiersprachen fur Proze~rechner Alle Sprachen, die zur ProzeBrechnerprogrammierung benutzt werden, nennt man Echtzeit-Sprachen (Real-Time-Sprachen). Man kann sie wie f o l g t klassifizieren: Klasse A: Maschinenorientierte Sprachen (z. B. PROSA 300) Klasse B: Erweiterungen p r o b l e m o r i e n t i e r t e r Sprachen (z.B. FORTRANErweiterungen) Klasse C: Kombinationen zwischen m a s c h i n e n o r i e n t i e r t e n und problemo r i e n t i e r t e n Programmiersprachen (z, B. POLYP ( 7 ) ) Klasse D: I n t e g r i e r t e Sprachen, die p r o b l e m o r i e n t i e r t e Sprachen (z.B, ALGOL 68 oder PL/I) als Basissprachen benutzen, aber eigene SchlUsselworte und Anweisungen f u r p r o z e B s p e z i f i s c h e Vorg~nge besitzen (zoBo PEARL ( I ) , (3) und (4)) Klasse E; Objektgebundene Sprachen (z.B, PROSPRO und MADAM f u r DDC ( 1 ) ) .

Die objektgebundenen $prachen sind nur f u r ein s p e z i e l l e s Aufgabengebiet k o n s t r u i e r t . Wit wollen jedoch die Sprachen der Klasse D b e t r a c h t e n : I n t e g r i e r t e Sprachen, mit denen neben Art auch Ort und Z e i t des Geschehens programmiert werden kann, Sie a l l e i n erlauben die uneingeschr~nkte Programmierung t e c h n i s c h e r Prozesse. 2. Aufgaben p r o z e B o r i e n t i e r t e r Prog_rammiersprachen Die prim~re Aufgabe der ProzeBrechner i s t es, die ( B i l d 2) a) Mengenprozesse (z,B, chemische I n d u s t r i e ) , b) FlieBprozesse (z.B. H~ttenwerke), c) StUckprozesse (z.B. H o c h r e g a l l a g e r ) , d) Teilnehmerprozesse (z.B. Bahnen) zu a u t o m a t i s i e r e n . Diese prim~ren Aufgaben sind jedoch aus Teilaufgaben zusammengesetzt ( B i l d 2), die w i t P r o z e B a I g o r i t h me n nennen: a) VerknUpfungsalgorithmen a.1) Berechnen, a.2) Optimieren, a.3) S i m u l i e r e n , a.4) P r o t o k o l l i e r e n . b) Erfassungs- und Versorgungsalgorithmen b.1) MeBwerterfassung, b.2) Stellgr~Benausgabe. c) Steuerungs- und Lenkungsalgorithmen c . I ) Zuordner, c.2) Folgesteuerungen, c.3) P a r a l l e l s t e u e r u n g e n .

VerknUpfung

V---l D

~

Funktionen

u. Lenken

Steuern

und Elemente

~

Sprach-

~

I

proze~orientierter

Transport~

Sprachen

operationel

TaSN~

~etr~ebs_ sprache

Ort und Z e i t

I ~ ~rund~ ~lemente

Art

E l e m e n t e

Tosk~og ~ - - - - / ~

Verarbeitung

ProgrammE 1 emente

Automo-K--i~~fasseo u.~----~ tisierung , Versorgen

Aufgaben

P r o z e s s A 1 g o r i t h m e n, ,, .,I

© L~P

204

Diese P r o z e ~ a l g o r i t h m e n

sind durch f o l g e n d e

P r o g r a m m e 1 e -

m e n t e darzustellen: a) A r i t h m e t i k und K e t t e n v e r a r b e i t u n g , b) D a t e n t r a n s p o r t e , c) Tasking (5) ( 6 ) . 3. Sprachelemente p r o z e ~ o r i e n t i e r t e r Die Programmelemente ben~tigen

ProqrammiersDrachen

zu i h r e r

Beschreibung wiederum bestimm-

te Sprachelemente. Die Sprachelemente f u r A r i t h m e t i k Datentransporte

und K e t t e n v e r a r b e i t u n g

mit Ausnahme der Proze~daten sind b e r e i t s

chert der S t u f e 4 (ALGOL 68 und P L / I ) Wenn w i r j e t z t

auch noch v e r l a n g e n ,

zeBorientierte

Programmiersprache

rechners g e n u t z t werden s o l l ,

sowie f u r in den Spra-

vorhanden. dad f u r

die v o l l e

so b l e i b t

eine neu zu sch~pfende proLeistung

eines D i g i t a l -

als Basissprache nur noch eine

der beiden Sprachen der Stufe 4 (ALGOL 68 oder P L / I ) Es genUgt d a b e i , v o n d e r Basissprache (z.B. Untermenge (Subset) zu ~bernehmen ( B i l d 3).

Ubrig.

ALGOL 68 oder P L / I )

nur eine

Fest verbunden mit den ProgrammteiTen, die die A r t des Geschehens im Proze~ bestimmen, s o l l e n die Programmteile s e i n , die das E c h t z e i t v e r h a l t e n des ProzeBrechners ( T a s k i n g ) den P r o b l e m t e i l .

Der P r o b l e m t e i l

ist

festlegen.

Beide zusammen b i l d e n

proze~spezifisch

und p r o z e ~ r e c h n e r -

unabh~ngig. In einem w e i t e r e n Programmteil~ dem S y s t e m t e i l , und Aufgaben u n t e r z u b r i n g e n , die im t e c h n i s c h e n arbeitung

die B e t r i e b s s p r a c h e

(Job Control

sind a l l e die Funktionen Bereich der D a t e n v e r -

Language, JCL) l e i s t e t .

In

diesem S y s t e m t e i l w i r d der Ort des Geschehens d e f i n i e r t . Den im Prob l e m t e i l b e n u t z t e n Namen f u r Ger~te und A n s c h l u ~ - S t e l l e n (z.B. Thermoelemente und I n t e r r u p t s i g n a l e ) werden b i e r Datenwege und P r o z e B s t e l l e n zugeordnet. Da zumindest die Datenwege n i c h t unabh~ngig von F a b r i k a t und Typ des Proze~rechners s i n d , muB der die K o n f i g u r a t i o n b e s c h r e i b e n d e S y s t e m t e i l bei e i n e r ~nderung der P r o z e ~ r e c h n e r - A u s r U s t u n g mit ge~ndert werden. Eine Programmiersprache, die diese Forderungen e r f U l l t , i s t PEARL. PEARL (Process and Experiment Automation R e a l - t i m e Language) i s t gemeinsam von deutschen H o c h s c h u l i n s t i t u t e n und Firmen e n t w i c k e l t worden (3),

(4).

3.1. V e r e i n b a r u n g der P r o z e B r e c h n e r - K o n f i g u r a t i o n Eine e x p l i z i t e Beschreibung der hardware-AusrUstung

(Struktur)

des Pro-

205

Bild 3

'ql

0

N 0

F--

E c~ L:.J

N

fly

E o

¢D N 0

I--

Gliederung proze~orientierter

Sprachen

2C6

ze#rechners hat folgenden Nutzen: Z u e r s t d i e n t sie zur F o r m u l i e r u n g der P r o z e B r e c h n e r - A u s r U s t u n g . Dann b e n ~ t i g t man sie zur optimalen Auswahl des B e t r i e b s s y s t e m s . S c h l i e ~ l i c h i s t sie das V e r z e i c h n i s a l l e r ProzeBs t e l l e n mit den dazugeh~rigen Namen, Die h a r d w a r e - B e s c h r e i b u n g i s t damit das verbindende Dokument f u r rung b e t e i l i g t e n

alle

an der P r o z e B r e c h n e r - P r o j e k t i e -

Gruppeno

Die Beschreibung der hardware-AusrUstung

des ProzeBrechners i s t

U b e r s i c h t l i c h und auch v o l l s t ~ n d i g , wenn a) baumartig v e r ~ s t e t e und vermaschte K o n f i g u r a t i o n e n gliedert

werden ( D a t e n w e g - B e s c h r e i b u n g ) .

zwei benachbarten D a t e n s t a t i o n e n bindung,

z,B,

dann

in Etappen ge-

Eine Etappe b e s t e h t aus

und der d a z w i s c h e n l i e g e n d e n Ver-

in der Form

datenstation

verbindungssymbol

datenstation;

b) A l l e D a t e n s t a t i o n e n sind nach dem g l e i c h e n Modus zu v e r e i n b a r e n . Die VereinbBrung mu# dabei mindestens f o l g e n d e Bestimmungsgr~Ben erfassen: b,1) Namen der D a t e n s t a t i o n e n

(wie Namen von P r o z e ~ s t e l l e n ,

Namen von

Ein-Ausgabewerken, Namen von Kan~len usw.) b.2) Typenbezeichnungen der D a t e n s t a t i o n e n ( e n t f ~ l l t bei P r o z e ~ s t e l l e n ) b.3) F u n k t i o n s a t t r i b u t der D a t e n s t a t i o n e n ( z . B . V e r s t ~ r k u n g s f a k t o r ) b.4) A n s c h l u B s t e l l e der D a t e n s t a t i o n ( f a l l s mehr als ein A n s c h l u # ) . c) FUr mehrere g l e i c h a r t i g e P r o z e B s t e l l e n ( z . B . 100 Thermoelemente)

und

ebenso f u r die A n s c h l u ~ s t e l l e n an der D a t e n s t a t i o n s o l l t e das D i m e n s i o n s a t t r i b u t z u l ~ s s i g s e i n . Damit w i r d die S c h r e i b a r b e i t r e d u z i e r t und die D b e r s i c h t l i c h k e i t erh~ht. d) FUr mehrere D a t e n s t a t i o n e n g l e i c h e n Typus ( z . B . mehrere Analoge~ngabewerke) s o l l t e der Typenbezeichnung ein Index b e i g e f U g t werden. e) Das V e r b i n d u n g s s y m b o 1 s e l l die Richtung des Datenflusses f)

anschaulich

darstellen

Die R e i h e n f o l g e der N i e d e r s c h r i f t ginnen und bei der Z e n t r a l e i n h e i t Datenflusses

Bild

sollte

ohne E i n f l u B

4 z e i g t ein B e i s p i e l

(z.B.

->, <-, <~>).

s o l l t e bei den P r o z e ~ s t e l l e n be(ZE, CPU) enden. Die Richtung des auf die Anordnung s e i n .

einer Proze~rechnerbeschreibung

(Konfigura-

t i o n s b e s c h r e i b u n g ) nach obigen R i c h t l i n i e n , Diese Beschreibung deckt s i c h weitgehend mit den Regeln yon PEARL. Am l i n k e n Rand sind die Namen a l l e r P r o z e ~ s t e l l e n ( z , B . TH1) a u f g e f U h r t und durch Doppelpunkt ( : ) von den Ein-Ausgabewerken g e t r e n n t .

207

Bild 4 /* V E ~ E I N B A R U N G

DER PROZESSRECHNERAKONFIGURATION

/* P R 0 Z E S S - S T E L L E N

:

THI

: -> A N E I N ( 1 )

TH2

:

TH(I:IO0)

:

MOD1

* I;

/* T H E R M O E L E M E N T E

* 2;

MOD2

A~mIN(2)

* 3(62)

+

* !(38);

TH2E

:

MOD1

* 39;

DRUME

:

MOD3

* 40; /* D R U C K M E S S E R

RE~I

: <- D I G A U S

* I~

RE~2

:

* 2;

ZIANZE

:

VENTIZ

:

* 3(12); * ]5;

SCHREMI

: <-> SMST;

*

4@**********

/* K A N A E L E

*~********

*/

/* R E L A I S

*/

/* Z I F F E R N A N Z E I G E

*/

/* SCI{REIBMASCHINE

*/ */

~* ~**********

** **~********

*/

:

AI~rEIN(1) <-> L~I; A N E i N ( 2 ) UKI

*/ */ */

<-> HK; SMST

<-> UKI; D I G A U S

<-> UKI;

<-> HK;

HK <-> ZE;

*/ /* I N T E R R U P T - S I G N A L E

:

/* I N T E R R U P T - S I G N A L E

V0N P R 0 Z E S S - S T E L L E N

*/ */

:

VERSINT

: -> PUG(2)

* I;

/* V E ~ S 0 ~ G U N G S S P A N N U N G S - A U S F A L L

UEBTEMP

:

* 2;

/* U E B E R T E M P E R A T U R

ENDLS 1

:

* 3;

/* E ~ D L A G E N S C H A Z T E R

1

*/

ENDLS2

:

* 4;

/* ENDLAGENSCHAT,TER

2

*/

TAST

:

* 5;

/* B E R E I C H S U E B E R S C H R E I T U N G E N BERAEI

: -> PUG(2)

* 8;

BERAE2

:

* 9;

/* D E F E K T M E L D U N G E N :

* 2;

DEFAE2 VERS

: :

* 3; * I;

ZAEUEB

:

DER TASTEN

*/

*!

*/

:

DEl~AE 1

/* Z A E H L E R U E B E R L A U F

/* S A M M E L I N T E R R U P T :

*/ */

*/

: * 7;

208

Das Thermoelement TH1 i s t schlossen.

an ein Analogeingabewerk vom TYP ANEIN ange-

Von diesem Typ werden zwei Ger~te b e n u t z t .

stimmte F u n k t i o n s a t t r i b u t e ,

die dutch ~IOD1 d e f i n i e r t

Ger~t b e l e g t TH1 die Klemme 1. Das Werk ANEIN(1) i s t Unterkanal

UKI angeschlossen, UK1 s e l b s t

ist

bunden, der wiederum mit der ZE g e k o p p e l t i s t . eindeutig

b e s c h r i e b e n e Datenweg, der bei

ANEIN(L) hat besind.

Auf diesem

wiederum an den

mit dem Hauptkanal

An der ZE endet nun der

dem Thermoelement TH1 begann.

3.2. P r o z e B l e n k u n q s t e i l A r t und Z e i t des Geschehens sind Sache des P r o z e B l e n k u n g s t e i l s Programms

(in

PEARL P r o b l e m - T e l l

HK v e r -

genannt).

des

Schwerpunkte im L e n k u n g s t e i l

sind: a) G r u n d a l g o r i t h m e n , b) DatenUbertragungen und c) Task-Steuerungen ( T a s k i n g ) . 3.2.1. Grundalgorithmen, Die Grundalgorithmen kann der ProzeBprogrammierer in einem Subset von ALGOL 68 oder PL/I b e s c h r e i b e n . A l g o r i t h m e n sind Operationen Uber Daten. Wir mUssen also zun~chst den Umfang der Datenmengen und dann den der Operatoren abgrenzen. 3.2.1.1.

Datenarten und Datentypen

Ein ProzeB b e n ~ t i g t

f o l g e n d e Datenarten

(Problemdaten):

a) Zahlen, b) Texte ( Z e i c h e n k e t t e n ) , ¢) B i t k e t t e n , d) Z e i t e n , d.1) d.2)

U h r z e i t (CLOCK), Dauer (DURATION),

e) Ger~te (DEVICE, I n t e r r u p t ,

Datei).

Da der Z a h l e n b e r e i c h eines Prozesses von sehr k l e i n e n bis zu sehr g r o Ben Werten r e i c h t ( O r i g i n a l w e r t e der ProzeBgr~Ben), sind neben F e s t punktzahlen

(FIXED, INTEGER, RAT) auch G l e i t p u n k t z a h l e n

(FLOAT, REAL)

zuzulassen. Ebenso w i c h t i g den A t t r i b u t e n richte

wie Zahlen sind Texte und B i t k e t t e n ( K e t t e n d a t e n mit CHAR, BIT und STRING). Texte sind die Datenform der Be-

und P r o t o k o l l e .

B i t k e t t e n werden in der S t e u e r u n g s t e c h n i k gebraucht ( z . B . Z u o r d n e r , F o l g e s t e u e r u n g e n , Zustandsbeschreibungen von L a g e r f ~ c h e r n usw.),

209

Die Z e i t e n

(Uhrzeit

Echtzeitverhalten

und Dauer) b e n ~ t i g t

zu b e s c h r e i b e n ,

der Proze~programmierer,

um das

die Proze~ger~te um den Ort des Ge-

schehens zu bestimmen. Neben diesen prim~ren

Problemdaten geh~ren noch die

s t e u e r u n g s d a t e n zum D a t e n v o r r a t tung und Umfang der Programmsteuerungsdaten ( z . Semavariable) weisung,

sind abet sehr von den D a t e n o p e r a t i o n e n

Tasking)

abh~ngig und s o l l e n

dann d o r t

In e i n e r Ausbaustufe der p r o z e ~ o r i e n t i e r t e n Adress-Variable stufe

P r o g r a m m -

e i n e r Sprache. BedeuB. Marken, Tasknamen,

(BASED-Variable,

2) zugelassen s e i n .

(z.B.

betrachtet

zur R e f e r e n z -

v e r l a n g e n den K e t t u n g s -

o p e r a t o r und den T e i l k e t t e n o p e r a t o r (SUBSTR). W e i t e r h i n k e t t e n o p e r a t o r e n UND, ODER und NICHT vorzusehen.

gen und V e r g l e i c h e 3.2.1.3, In a) b) ¢)

sind einige

wie SIN, COS, ABS, MAX, MIN und SIGN

Die T e x t - und B i t k e t t e n v e r a r b e i t u n g

FUr die Z e i t v a r i a b l e n

Aus-

und rasche Bear-

3 . 2 . 1 . 2 . Operatoren und S t a n d a r d f u n k t i o n e n Neben der v o l l e n A r i t h m e t i k f ~ r F e s t - und G l e i t p u n k t z a h l e n erwUnscht.

sollten

erlauben eine r a t i o n e l l e

nutzung des S p e i c h e r p l a t z e s ( i n d i r e k t e A d r e s s i e r u n g ) b e i t u n g von T a b e l l e n , L i s t e n und Proze~datenbanken.

Operatoren und S t a n d a r d f u n k t i e n e n

werden.

Programmiersprache

POINTER oder V a r i a b l e

Diese V a r i a b l e

Sprungan-

sind manche a r i t h m e t i s c h e

zuzulassen ( z . B .

Addition,

sind die B i t -

und l o g i s c h e

Sub~traktion,

Verkn~pfunVergleiche).

Anweisungen

einem Proze~programm werden f o l g e n d e Anweisungen b e n S t i g t : Ergibtanweisung (Wertzuweisung), Sprunganweisung (GOTO), Verzweigung ( I F - A n w e i s u n g ) ,

d) Wiederholungsanweisung e) P r o z e d u r a u f r u f

(FOR - BY - TO - WHILE) und den

(CALL) mit P r o z e d u r v e r e i n b a r u n g e n .

A l l e Parameter de~ Anweisungen~ g l e i c h ob auf I n d e x p o s i t i o n oder Argum e n t p o s i t i o n m~ssen mit Formeln ( e x p r e s s i o n ) b e s e t z t werden k~nnen. Z . B . : CALL UP(A+B/SlN(D-F), M/N, B&C&D); FOR LAUF := A*B BY K/L TO R+K 3.2.2.

WHILE(B&F);

E i n - und Aus~abe von Date n

Beim ProzeBrechner sind E i n - A u s g a b e - T r a n s p o r t e a) ProzeBdaten, b) B e n u t z e r d a t e n und c) S p e i c h e r d a t e n zu v e r a n l a s s e n ,

von

210

Alle drei

Klassen von Transporten u n t e r l i e g e n u n t e r s c h i e d l i c h e n Gesetzen.

ProzeBdaten sind g l e i c h

den Benutzerdaten wortweise a l s auch blockweise

zu Ubertragen, Speicherdaten nur b l o c k w e i s e .

Die Benutzerdaten sind aus-

serdem in eine v e r e i n b a r t e Form (FORMAT, PICTURE) zu UberfUhren. 3.2.2.1.

Proze~daten Ein- und Ausgabe

Der T r a n s p o r t von Proze~daten i s t

eine B e s o n d e r h e i t der Proze~rechner.

Entsprechende T r a n s p o r t a k t i o n e n sind im t e c h n i s c h - w i s s e n s c h a f t l i c h e n und kaufm~nnischen Rechnen unbekannt.

Es i s t

deshalb zweckm~Big, f u r d i e

T r a n s p o r t e yon Proze~daten besondere S c h l U s s e l w o r t e e i n z u f U h r e n ,

z.B.:

MOVE d a t e n q u e l l e TO datensenke; Die MOVE-Anweisung t r a n s p o r t i e r t

Daten yon Q u e l l e zu Senke

'Startort

zu Z i e l o r t ) . Entweder Quelle oder Senke oder beide sind in der MOVE-Anwelsung Proze~stellen.

Die P r o z e B s t e l l e w i r d durch

ihren Proze~stellen-Namen v e r t r e -

t e n , wie er im S y s t e m t e i l der P r o z e ~ r e c h n e r - K o n f i g u r a t i o n bekannt gemacht wurde.

Bei e i n e r Eingabe i s t

beitsspeicher,

die Senke eine S p e i c h e r z e l l e im Ar-

bei der Ausgabeanweisung l i e g t

die Q u e l l e im A r b e i t s -

speicher. Beispiel: MOVE THERMO TO TEMP; MOVE TEMP TO ANZEIG; MOVE KONT1 TO RELAIS; THERMO (Thermoelement), A N Z E I G ( Z i f f e r n a n z e i g e ) , KONTI (Kontakt I ) R E L A I S ( S t e l l g l i e d ) sind P r o z e # s t e l l e n .

Diese Namen mUssen deshalb im

SYSTEM-Teil eines PEARL-Programms bekannt gemacht worden s e i n . PROBLEM-Teil

und

Im

sind diese Namen als Ger~te ( P r o z e B s t e l l e n ) zu v e r e i n b a -

ren (DEVICE), damit der Compiler s i e n i c h t m i t den V e r s ~ u m n i s - A t t r i b u t e n versieht spiel

(z.B.

BIN FIXED ( 1 5 ) ) .

TEMP (Temperatur) i s t

in unserem B e i -

eine V a r i a b l e im A r b e i t s s p e i c h e r .

3 . 2 . 2 . 2 . Benutzerdaten E i n - und Aus~abe Der T r a n s p o r t der Benutzerdaten w i c k e l t sich zwischen T a s t a t u r e n ,

Konsol-

schreibmaschinen, P r o t o k o l l s c h r e i b m a s c h i n e n auf a l l e n Ebenen der Bedien u n g s h i e r a r c h i e ab. In der Transportanweisung muB deshalb das Z i e l genannt werden, auf dem ein P r o t o k o l l ausgegeben werden s o l l oder die Quell e , v o n der man Daten e r w a r t e t .

Die Zuordnung zwischen den Namen von Z i e l

oder Q u e l l e und dem w i r k l i c h e n

Ger~t ( z . B .

Bildschirm)

ist

im S y s t e m t e i l anzugeben.

P r o t o k o l l s c h r e i b m a s c h i n e oder

211

Da d i e s e r D a t e n t r a n s p o r t

nicht

f u r die Anweisungen von PL/I

prozeBspezifisch

ist,

man h i e r -

oder ALGOL 68 Ubernehmen. In PL/I

die S c h l U s s e l w o r t e

GET und PUT (STREAM-Dateien), z . B .

LIST ( ' P u m p s t a t i o n

1 DEFEKT').

3,2.2.3.

sollte

sind es

PUT FILE (KONSOL)

Spe!cherdaten-Transport

S p e i c h e r d a t e n sind Datenmengen, die zwischen dem A r b e i t s s p e i c h e r

der ZE

und einem e x t e r n e n S p e i c h e r (Band oder P l a t t e ) t r a n s p o r t i e r t werden. S p e i c h e r d a t e n b l e i b e n im Gegensatz zu den B e n u t z e r d a t e n und ProzeBdaten "im System". FUr den T r a n s p o r t der S p e i c h e r d a t e n sind sowohl in PL/I als auch in ALGOL 68 genUgend l e i s t u n g s f ~ h i g e Anweisungen vorhanden ( z . B . READ, WRITE, REWRITE und DELETE in P L / I ) . Im P r o z e ~ r e c h n e r b e t r i e b muB jedoch d e u t l i c h e r als es in PL/I g e s c h i e h t zwischen Dateien (FILE) und D a t e n t r ~ g e r n u n t e r s c h i e d e n werden. Dateien sind benannte Datenmengen, die g l e i c h z e i t i g oder nacheinander auf v e r schiedenen D a t e n t r ~ g e r n u n t e r g e b r a c h t s i n d . Ein D a t e n t r ~ g e r dagegen i s t ein t e c h n i s c h e s Ger~t oder ein G e r ~ t e t e i l ( z . B . P l a t t e 2, Z y l i n d e r 4, Spur 6, Segment 7). Obernimmt das B e t r i e b s s y s t e m die Auswahl des S p e i c h e r p l a t z e s auf der P l a t t e oder die Auswahl e i n e r P l a t t e von mehreren, so s o l l t e es dem Programmierer m~glich sein v o r z u s c h r e i b e n , ob die Datei auf e i n e r l a n g samen oder s c h n e l l e n 3.2.3.

Platte

unterzubringen

ist

(RESIDENT-Anweisung),

Tasking

Da der ProzeBrechner im E c h t z e i t - B e t r i e b mehrere Aufgaben g l e i c h z e i t i g zu e r f U l l e n h a t , muB die T a s k - A b w i c k l u n g l e i c h t zu programmieren s e i n . S t a r t , Unterbrechung und L~schung e i n e r Task sind a n s c h a u l i c h d a r z u s t e l len. Eine Task i s t die AusfUhrung eines Programms Z e i t und b e l e g t B e t r i e b s m i t t e l .

(5).

Eine Task v e r b r a u c h t

Nur benannte ProgrammstUcke mit dem A t t r i b u t TASK s o l l e n als Task zugelassen s e i n , Prozeduren n i c h t . Aber Prozeduren kSnnen im Rumpf e i n e r Task a u f g e r u f e n werden. Beispiel: PALM: TASK; taskrumpf CALL UP2 ( - - , taskrumpf END;

--,

--);

212

UP2: PROCEDURE ( - - ,

--,

--);

prozedurrumpf END; Folgende Taskklassen s o l l t e n

vorgesehen s e i n :

a)

Haupttask ( S c h l U s s e l w o r t TASK MAIN). Sie w i r d beim P r o z e ~ s t a r t mit gegebener P r i o r i t ~ t yon der Konsole g e s t a r t e t ~

b)

Arbeitstasks

( S c h l U s s e l w e r t TASK). Sie werden von e i n e r AusfUhrungs-

bedingung e i n e r Taskanweisung m a n i p u l i e r t . Die Taskabwicklung w i r d das KernstUck jedes Proze~programms s e i n . Die Taskabwicklung muB der Programmierer durch die Taskanweisungen f e s t legen. Die

T a s k a n w e i s u n g

erstreckt

sich Uber:

a) AusfUhrungsbedingung, b) T a s k o p e r a t i o n , c) T a s k - P r i o r i t ~ t . Beispiel: AT 08:30 EVERY 1MIN UNTIL 15:30 ACTIVATE PALM PRIORITY(47); Die Task mit dem Namen PALM w i r d ab 8 Uhr 30 bis mit der P r i o r i t ~ t 3.2.3.1.

Taskoperationen

Eine Task kann f o l g e n d e Zust~nde annehmen ( B i l d a) n i c h t

15 Uhr 30 jede Minute

47 g e s t a r t e t .

5):

existent,

b) v e r e i n b a r t , Der Wechsel zwischen diesen beiden Zust~nden w i r d durch den E i n t r i t t und A u s t r i t t

des taskumfassenden Blocks v e r a n l a B t .

I s t die Task v e r e i n b a r t , dann kann sie durch die A k t i v i e r u n g s a n w e i s u n g ACTIVATE in den Zustand v e r z e i c h n e t ( a r r a n g e d ) gelangen. J e t z t i s t sie vom B e t r i e b s s y s t e m in die W a r t e l i s t e aufgenommen. Sie w i r d vom B e t r i e b s system g e s t a r t e t und damit in den Zustand a k t i v U b e r f U h r t , sobald die Task-Priorit~t dies e r l a u b t . Der A k t i v - Z u s t a n d

hat wiederum zwei U n t e r z u s t ~ n d e :

a) a u s f U h r b a r , b) wartend. Die Task kann nun durch die beiden Anweisungen SUSPEND ( Z u r U c k s t e l l e n )

nicht ~xistent

vereinbart

TA

(arranged)

S K Z U S T~

aktiv

verzeichnet

(declared)

N D E

CONTINUE

SUSPEND r~

214

oder DELAY ( U n t e r b r e c h e n )

in den Wartezustand Ubergehen.

Vom Wartezustand g e l a n g t die Task wieder in den Zustand " a u s f U h r b a r " durch die Anweisung CONTINUE ( W e i t e r f U h r e n ) . Anweisung auf. Eintreten

CONTINUE hebt die SUSPEND-

Der Wartezustand nach der DELAY-Anweisung w i r d durch das

eines E r e i g n i s s e s ,

das in der DELAY-Anweisung als Parameter

genannt wurde, beendet. Ein v o r z e i t i g e s

Abbrechen e i n e r Task kann der Programmierer durch die

Anweisung TERMINATE (Beenden) b e f e h l e n . Der S t a r t

e i n e r Task im Zustand " v e r z e i c h n e t "

PREVENT ( V e r h i n d e r n )

kann durch die Anweisung

unterbunden werden.

3.2.3.2. AusfUhrunqsbedinqun~en Zu welchem Zeitpunkt eine Taskoperation ausgefUhrt werden s o i l , bestimmt der Programmierer in den AusfUhrungsbedingungen. Die AusfUhrungsanl~sse einer Task sollten sein: a) Zeiten. a.1) Uhrzeit (CLOCK), a.2) Z e i t i n t e r v a l l , Dauer (DURATION), b) Interruptsignale. FUr alle AusfUhrungsanl~sse sind spezifische SchIUsselworte zu e r s t e l len, die in den Programmiersprachen PL/I und ALGOL 68 nicht vorhanden sind. In PEARL wird deshalb folgendes vorgeschlagen: AT uhrzeitformel, AFTER dauerformel, EVERY dauerformel,

DURING dauerformel,

UNTIL uhrzeitformel, FUr viele Zwecke i s t die VerknUpfungsfunktion CONJUNCT, DISJUNCT, JUNCTION zweckm~Big; JUNCTION zum Warren auf den letzten yon mehreren Startereignissen, DISJUNCT zum Warten auf den ersten yon mehreren Startereignissen. Die CONJUNCT-Funktion i s t nur dann e r f U l l t , wenn alle Startereignisse gemeinsam eintreffen. 3.2.3.3.

Interruptbehandlun~,

Wir mUssen zwischen a) Proze~interrupt und b) Systeminterrupt unterscheiden.

215

P r o z e ~ i n t e r r u p t s Proze~stellen Z~hlern bei

sind

usw.).

(Kontakte,

sind bin~re

Interruptquellen

PEARL) zu v e r e i n b a r e n

Signale,

Bereichsmelder, sind

(siehe

im K o n f i g u r a t i o n s t e i l

Bild sind

mit Standardcharakter

ZERODIVIgE u s w , ) ,

Sowohl P r o z e ~ i n t e r r u p t s bedingungen fur

Tasks

als

rechnerinterne

auch S y s t e m i n t e r r u p t s

zugelassen

von

(SYSTEM-Teil

4).

S y s t e m i n t e r r u p t s (OVERFLOW,

deren Q u e l l e n

Oberlaufimpulse

sein.

Hier

Interruptsignale

sollen

sind jedoch

als

AusfUhrungs-

zwei F ~ l l e

zu

unterscheiden: a) A u s l ~ s e n e i n e r b) V e r z w e i g e n

Taskoperation

innerhalb

Das A u s l ~ s e n e i n e r werden,

einer

(z.B.

ACTIVATE, TERMINATE),

Task.

Taskoperation

sollte

durch

WH E N

gesteuert

z.B.:

WHEN UEBTEMP ACTIVATE . . . ; WHEN OVERFLOW T E R M I N A T E . . . ; Wird

innerhalb

Task n i c h t ,

einer

lediglich

gen s o l l t e

Task v e r z w e i g t , der

Inhalt

so ~ n d e r t

sich

der Task w i r d

d u t c h das S c h l U s s e l w o r t

0 N

der Z u s t a n d der

v e r ~ n d e r t . Das V e r z w e i -

gesteuert

werden.

Z.B.: TEMPAL : PROCEDURE; MI:

...... ON OVERFLOW GOTO M I ,

Verzweigt

darf

nut innerhalb

f U h r u n g s b e d i n g u n g zu e i n e r 3.2.3.4.

Sperren

Systeminterrupts gesperrt

Die

Die

k~nnen d u r c h d i e REVERT w i e d e r

der P r o z e ~ i n t e r r u p t s

~ u ~ e r e

l~sen) die zulassen.

Maskierung

Interrupt-Signale

i n n e r e

wirksam)

kierung

Ublichen

nicht

in einer

Aus-

Anweisungen wie NOOVERFLOW

freigegeben

werden.

n e n n t man

M a s k i e r e n .

(verlierbar)

sperren

Maskierung

eingeleitet

Der P r o g r a m m i e r e r

Prozedur werden,

von I n t e r r u ~ t s i g n a l e n _

und d u t c h

Das S p e r r e n

einer Task.

soll

(unverlierbar)

wird

und d u t c h ENABLE ( w i r k s a m ) mud d i e M ~ g ! i c h k e i t e n

abzufragen.

Dazu i s t

die

d u r c h DETACH ( L o s -

und d u r c h ATTACH ( A n h e f t e n )

besitzen,

auskunftgebende

wieder

d u r c h DISABLE ( u n -

wieder

aufgehoben.

den Z u s t a n d der MasStandardfunktion

216

DISABLED(Interruptname)

zweckm~ig.

Beispiel: IF DISABLED(UEBTEMP) THEN MOVE TH23 TO TEMP; 3.2.3,5. Taskpriorit~t Mit dem Namensaufruf e i n e r Task kann g l e i c h z e i t i g vom Programmierer die Taskpriorit~t v o r g e s c h r i e b e n werden. Der Programmierer hat die M ~ g l i c h keit,

ein Programm als Task n i e d e r e r

und s p a r e r das g l e i c h e Programm

als Task h~herer P r i o r i t E t a u f z u r u f e n . Eine programmierbare P r i o r i t ~ t s ~nderung w i r d auch bei p r o z e ~ o r i e n t i e r t e n Sprachen b e n ~ t i g t . Durch die auskunftgebende S t a n d a r d f u n k t i o n liebiger

Stelle

die a k t u e l l e

PRIORITY kann der Programmierer an be-

Prior it~t

e i n e r Task abfragen.

Z.B.:

IF PRIORITY (CHEFTASK) < PRIORITY (UNTrASK) THEN PRIORITY(CHEFTASK)

:= PRIORITY(UNTTASK)

+ 10~

3 . 2 . 3 . 6 . K o o r d i n i e r e n yon Tasks Unter K o o r d i n i e r e n von Tasks w o l l e n w i r das a) B l o c k i e r e n und b) S y n c h r o n i s i e r e n verstehen. 3.2.3.6.1. Blockieren G r e i f e n mehrere Tasks kann der Programmierer Tasks ein Unheil n i c h t

yon Tasks gleichzeitig zu einem B e t r i e b s m i t t e l zu, dann Uber u n t e r s c h i e d l i c h e P r i o r i t ~ t e n der e i n z e l n e n v e r h i n d e r n . Das g e e i g n e t e Programmelement zum

Schutz von B e t r i e b s m i t t e l n i s t die Semaphor-Variable muB im P r o b l e m t e i l

S e m a p h o r - V a r i a b l e . Die v e r e i n b a r t werden ( A t t r i b u t SEMA).

Jedes B e t r i e b s m i t t e l ( z . B . S p e i c h e r b e r e i c h , Datenbank, P r o t o k o l l s c h r e i b m a s c h i n e ) , z u dem aus i r g e n d w e l c h e n GrUnden mehrere Tasks n i c h t g l e i c h z e i t i g Zugang e r h a l t e n dUrfen, i s t dutch eine Semaphorvariable zu schUtzen. Dem Z u g r i f f muB die REQUEST-Anweisung "REQUEST(semavariable)" vorangehen. Die REQUEST-Anweisung und a l l e folgenden Anweisungen werden n i c h t a u s g e f U h r t , wenn die zugeh~rige Semavariable Null i s t , Eine ausfUhrbare

REQUEST-Anweisung v e r r i n g e r t

die Semavariable um Eins.

Hat die z u g r e i f e n d e Task i h r e n A u f t r a g d u r c h g e f U h r t , so mud der Programmierer durch die Anweisung RELEASE ( s e m a - v a r i a b l e ) den nachdr~ngenden Tasks das B e t r i e b s m i t t e l w i e d e r f r e i g e b e n . Haben mehrere Tasks auf die Freigabe g e w a r t e t , triebssystem

so s t a r t e r

die Task mit der h~chsten P r i o r i t ~ t .

jetzt

das Be-

217

Auch h i e r w~re eine auskunftgebende S t a n d a r d f u n k t i o n zweckm~Big, um w i c h t i g e n rit~t

Tasks in der Warteschlange

zu geben oder ein A u s w e i c h - B e t r i e b s m i t t e l

3.2.3.6.2.

Synchronisieren

(z.B.

REQUESTED)

eine h~here P r i o -

zu benutzen.

yon Tasks

Zum S y n c h r o n i s i e r e n von Tasks dienen b i n ~ r e V a r i a b l e , sog. E r e i g n i s v a r i a b l e ( A t t r i b u t EVENT). E r e i g n i s v a r i a b l e sind Programmsteuerungsgr~Ben, die in b e l i e b i g e n g e l ~ s c h t werden k~nnen.

Tasks mit SET g e s e t z t und mit RESET w i e d e r

Die E r e i g n i s v a r i a b l e sind Argumente in den AusfUhrungsbedingungen CONJUNCT, DISJUNCT oder JUNCTION oder in e i n e r Warteanweisung (WAIT). Die WAIT-Anweisung u n t e r b r i c h t Argumentformel e r f U l l t ist.

die b e t r o f f e n e

Task so l a n g e , bis

ihre

Z.B.: JUNCTION(El, E2, E3) ACTIVATE TASK13 PRIO(20); WAIT(E1]E2&E3) ; Die im Programm durch SET oder RESET bedienten E r e i g n i s v a r i a b l e k~nnen durch DISABLE und ENABLE g e s p e r r t und f r e i g e g e b e n werden. Auch b i e r muB der Programmierer die M ~ g l i c h k e i t haben, r U c k z u f r a g e n , in w~Ichem Zustand sich die E r e i g n i s v a r i a b l e b e f i n d e t : Auskunftgebende S t a n d a r d f u n k t i o n DISABLED. 4. Form p r o z e B o r i e n t i ~ r t e r Programmiersprachen (Zusammenfassun~l Eine p r o z e B o r i e n t i e r t e Programmiersprache muB f o l g e n d e Forderungen e r fUllen: a) der Sprachumfang muB a u s r e i c h e n , zu k~nnen. b) Die Sprache s o l l grammteile s o l l e n guration sein.

portabel

sein,

um b e l i e b i g e

d. h. die p r o b l e m s p e z i f i s c h e n

unabh~ngig v o n d e r

c) Die Form der p r o z e B o r i e n t i e r t e n

Prozesse programmieren Pro-

benutzten ProzeBrechner-Konfi-

Programmiersprachen

soll

an die Form

der Basissprache ( z . B . PL/I oder ALGOL 68) angepa~t s e i n . Die e i n h e i t l i c h e Form e r l e i c h t e r t das Lernen und s c h ~ r f t das S p r a c h g e f U h l . d) Die S c h l U s s e l w ~ r t e r der Sprache s o l l e n s p r e c h b a r und i h r e F u n k t i o n e r k e n n b a r s e i n . ProzeBprogramme sind auf groBe Lebensdauer a n g e l e g t , s i e mUssen deshalb Dokumentcharakter haben. Solche Programme mUssen sich s e l b s t b e s c h r e i b e n . Das geht n u r , wenn die S c h l U s s e l w o r t e i h r e n Sinn auf den e r s t e n B l i c k erkennen l a s s e n . e)

Im Vordergrund mUssen die Belange und G e p f l o g e n h e i t e n stehen. Die A u t o m a t i s i e r u n g des Prozesses i s t p r o z e B o r i e n t i e r t e n Programmiersprache.

der Anwender

das prim~re Z i e l

einer

218

Nur eine Programmiersprache, die diese Forderung e r f U l l t , s i c h e r t sich eine weite Verbreitung, sie kann Wegbereiter einer i n t e r n a t i o n a l e n Normierung werden. 5. L i t e r a t u r h i n w e i s e (i) Binge, K. und Koch, G.: I n t e r p r e t i e r e n d e p r o b l e m o r i e n t i e r t e und objektgebundene Programmsysteme f u r ProzeBrechner, 5. INTERKAMA 1971 (2)

Higman: Programmiersprachen f u r D i g i t a l r e c h n e r , MUnchen, 1972

Carl-Hanser-Verlag,

(3)

K.H. Timmesfeld, B. SchUrlein, P. Rieder, K. P f e i f f e r , G. MUller, K. Kreuter, P. Holleczek, V. Haase, L. F r e v e r t , P. E l z e r , S. Eichentopf, B. Eichenauer, J, Brandes: PEARL - Vorschlag fur eine ProzeB- und Experimentautematisierungssprache, Gesellschaft fur Kernforschung mbH, Karlsruhe, PDV-Bericht KFK-PDV I , April 1973

(4)

Eichenauer, B., Haase, V., Holleczek, P I . , Kreuter, K. und MUller, G.: PEARL, eine proze~- und e x p e r i m e n t o r i e n t i e r t e Programmiersprache, Angewandte Informatik 9/73, Seite 363 his 372

(5)

Kussl, V.: Technik der ProzeBdatenverarbeitung, Carl-Hanser-Verlag, MUnchen, 1973

(6)

Bauer, F.L. und Goos, G.: I n f o r m a t i k ,

Springer-Verlag

1971

(Heidelberger TaschenbUcher) (7)

MuBtopf, G.: Das Programmiersystem POLYP, Angewandte I n f o r m a t i k , Heft 10/1972, Seite 441 bis 448

A n s c h r i f t der Verfasser: Dipl.-Math. Gerhard Koch, BBC, 68 Mannheim, Abt. ZEK-ED, und D i p l . - I n g . Volkmar Kussl, BBC, 68 Mannheim, Abt. ZAF/B

EIN V E R G L E I C H VON P R O Z E S S - K O N T R O L L - S P R A C H E N ALS BASIS F U R DEN N O R M L ~ G S V O R S C H L A G E I N E R INTERNATIONALEN PROZESSRECHNERSPRACHE

K. F. E R E U T E R

Sp~testens

seit E r s c h e i n e n des Buches

'Programming Languages'

yon

Jane E. Sammet, das als T i t e l b i l d ein B a b y l o n i s c h e r Turm ziert, dessen B a u s t e i n e jeder einen anderen P r o g r a m m i e r s p r a c h e n - N a m e n sich die W e l t der e i n s c h l ~ g i g b e l a s t e t e n

tr~gt,

ist

I n f o r m a t i k e r einig darin,

dab es zu viele P r o g r a m m i e r s p r a c h e n gibt. Die G e b ~ r f r e u d i g k e i t der S p r a c h e r f i n d e r hat indes seitdem k e i n e s w e g s nachgelassen° mittel,

die zum Bau yon C o m p i l e r n mehr und mehr

Die Hilfs-

zur V e r f 0 g u n g stehen,

m a c h e n es im G e g e n t e i l immer leichter, neue Sprachen nicht nur zu erfinden,

sondern w o m ~ g l i c h

auch zu implementieren.

S t a n d a r d i s i e r u n ~ und N o r m u n 9

Es ist m H B i g d a r ~ b e r

zu p h i l o s o p h i e r e n ,

den werden, w a r u m jeder e n g a g i e r t e Sprache e n t w i c k e l t

w a r u m so v i e l e S p r a c h e n erfun-

Informatiker

lieber eine neue

als die des N a c h b a r n zu benutzen.

Man sollte sich

start d e s s e n fragen, w a r u m es nut sehr schwer gelingt, einen g r ~ B e r e n A n w e n d e r k r e i s

einer Sprache

zu e r s c h l i e B e n und sie w o m ~ g l i c h

zu einem

a n e r k a n n t e n S t a n d a r d zu erheben.

Die Tatsache,

dab neben u n z i h l i g e n N o r m e n Hber B e g r i f f e und Sinnbilder,

z.B. die S c h a l t z e i c h e n der A n a l o g r e c h e n t e c h n i k , Masehinelle

~ber Codierung,

~ber

Z e i c h e n e r k e n n u n g usw. erst drei - g e m e s s e n am Stand der

E n t w i c k l u n g - e i g e n t l i c h schon h i s t o r i s c h e P r o g r a m m i e r s p r a c h e n (ALGOL, F O R T R A N und COBOL) sollte n a c h d e n k l i c h

in die N o r m e n b l ~ t t e r a u f g e n o m m e n wurden,

stimmen.

rien der N o r m u n g s g r e m i e n

Es e n t s t e h t der Eindruck, dab die Krite-

auf d i e s e m G e b i e t u n z u r e i c h e n d sind.

220

Immerhin zeigen das Beispiel PL/I und die Bem~hungen, ECMA u n t e r n o m m e n haben, dab das Kriterium: Rechnern v e r s c h i e d e n e r Hersteller

PL/I steht er vor der T~r) w i c k l u n g e n bzw.

'auf u n t e r s c h i e d l i c h e n

implementiert',

g u n s t e n des u m g e k e h r t e n Verfahrens:

die ANSI und

a u f z u g e b e n ist zu-

E i n i g u n g auf einen Standard

und dann Implementationen,

U n v e r t r ~ g l i c h k e i t e n zu vermeiden.

(ffir

um D o p p e l e n t -

Dies ist das Ziel,

das den N o r m u n g s w ~ n s c h e n in anderen B e r e i c h e n der Technik seit langem zugrunde liegt.

Universelle ProzeBrechners~rache

Seit Jahren bemfiht sich eine A r b e i t s g r u p p e ,

die sich aus p o t e n t i e l l e n

A n w e n d e r n einer P r o z e B r e c h n e r s p r a c h e g e b i l d e t hat~ eine solche Sprache bis zum N o r m u n g s v o r s c h l a g voranzubringen.

Wie schwer es aber ist, m i t

Standardisierungswfinschen zu k o n k r e t e n E r g e b n i s s e n

zu kommen,

das S c h i c k s a l des L o n g - T e r m - P r o c e d u r a l - L a n g u a g e - C o m m i t t e e s

zeigt

des

'Purdue W o r k s h o p s on S t a n d a r d i z a t i o n of Industrial C o m p u t e r Languages', das sich seit 1969 d a r u m bemfiht, einen S p r a c h v o r s c h l a g rechnersprache

ffir eine ProzeB-

zu e r a r b e i t e n - auf der G r u n d l a g e yon PL/I - und diesen

in der ANSI m ~ g l i c h s t zusammen m i t den dort laufenden Bemfihungen um eine S % a n d a r d i s i e r u n g yon PL/I selbst zu koordinieren. chem p e r s o n e l l e n E n g a g e m e n t gelang es nicht, Zeitrahmens das ge-~inschte Ziel zu erreichen, sten Jahres

Trotz erhebli-

i n n e r h a l b des g e s e t z t e n so dab der A n f a n g n~ch-

zu e r w a r t e n d e P L / l - V o r s c h l a g von seiten ANSI - E C M A ohne

jede V e r z i e r u n g mit P r o z e B s p r a c h e n e l e m e n t e n e r s c h e i n e n wird.

V o r a r b e i t e n ffir einen S t a n d a r d i s i e r u n ~ s v o r s c h l a ~

Die E u r o p ~ i s c h e n T e i l n e h m e r an dem zweimal j~hrlich s t a t t f i n d e n d e n W o r k s h o p der Purdue U n i v e r s i t y in L a f a y e t t e / I n d i a n a w a r e n nicht angetan von dem seitens der U S - A m e r i k a n e r e i n g e s c h l a g e n e n Weg, Standardisierungsvorschlag

zu gelangen.

zu e i n e m

Sie b i l d e t e n d e s h a l b die

E u r o p ~ i s c h e Gruppe des LTPLC, und trafen sich etwa alle zwei Monate, um die e i g e n e n V o r s t e l l u n g e n

zu d i s k u t i e r e n und m 6 g l i c h e r w e i s e

zu

einem g e m e i n s a m e n V o r s c h l a g zu kristallisieren.

Trotz e r h e b l i c h e n

Einsatzes yon Geist und Geld hat sich auch hier

noch kein g r e i f b a r e r Erfolg eingestellt.

Als G r u n d l a g e ffir einen m~g-

l i c h e r w e i s e zu v e r a b s c h i e d e n d e n S p r a c h v o r s c h l a g w i r d zur zeit eine

221

a n s p r u c h s v o l l e Studie b e t r i e b e n ,

die anhand von u m f a n g r e i c h e n Fragen-

k a t a l o g e n - o r i e n t i e r t an dem, was f~r eine Sprache allgemein, eine P r o z e B s p r a c h e

insbesondere,

v e r s c h i e d e n e S p r a c h e n vergleicht. ~ b e r s t e l l u n g der A n t w o r t e n

fHr

als n o t w e n d i g e r a c h t e t w i r d - f~nf Dies g e s c h i e h t zuerst durch Gegen-

zu den v e r s c h i e d e n e n Fragen.

Es h a n d e l t

sich um die P r o g r a m m i e r s p r a c h e n A L G O L 68, CORAL 66, PASI - BBC PL/I~ PEARL, PROCOL.

Die A u s w a h l der S p r a c h e n ist in s t a r k e m MaBe dadurch gepr~gt,

dab die

M i t g l i e d e r der A r b e i t s g r u p p e p e r s ~ n l i c h oder durch den A r b e i t g e b e r veranlaBt,

an den e i n z e l n e n S p r a c h e n i n t e r e s s i e r t sind - v o n

bei abgesehen.

A L G O L 68 da-

Der V o l l s t ~ n d i g k e i t halber seien die A b s i c h t e n und Zie-

le, die den e i n z e l n e n S p r a c h e n zugrunde liegen, kurz umrissen.

A L G O L 68

wurde vonder

W o r k i n g Group

2.1 der IFIP entwickelt,

die

damit ihren G l a u b e n an den W e r t einer u n i v e r s e l l e n P r o g r a m m i e r s p r a c h e fur viele v e r s c h i e d e n e A n w e n d e r

in v i e l e n L ~ n d e r n a u s d r ~ c k e n wollte.

A L G O L 68 ist d a z u bestimmt, A l g o r i t h m e n

zu f o r m u l i e r e n und w e i t e r z u g e -

ben, diese e f f i z i e n t auf einer V i e l z a h l von C o m p u t e r n a u s f ~ h r e n zu k~nnen und den e i n s c h l ~ g i g e n U n t e r r i c h t

CORAL 66 basiert,

zu erleichtern.

ist eine u n i v e r s e l l e P r o g r a m m i e r s p r a c h e ,

die auf A L G O L 60

die d a n e b e n E l e m e n t e von Jovial und F O R T R A N enth~it.

de e n t w i c k e l t ,

Sie wur-

um eine h ~ h e r e S p r a c h e zu haben, d e r e n U b e r s e t z u n g mit

g e r i n g s t e r A n l a g e n a u s s t a t t u n g einen e f f i z i e n t e n Code zu e r z e u g e n gestattet.

Diese Z i e l v o r s t e l l u n g

liegt h e u t z u t a g e a ! i g e m e i n den sogenann-

ten n i e d e r e n P r o g r a m m i e r s p r a c h e n

zugrunde.

W i c h t i g ist jedoch, dab

C O R A L 66 in G r o B b r i t a n n i e n i n z w i s c h e n als S p r a c h s t a n d a r d

fHr m i l i t ~ r i -

sche P r o g r a m m i e r a u f g a b e n e i n g e f H h r t ist.

PASI - BBC PL/I ohne R H c k g r i f f e

ist ein Z w e i g e s p a n n von Sprachen, mit d e r e n Hilfe

auf den A s s e m b l e r P r o g r a m m s y s t e m e

in R e a l z e i t u m g e b u n g

f o r m u l i e r t w e r d e n k~nnen.

fHr P r o z e B a u f g a b e n

Dabei w e r d e n in den in

PASI g e s c h r i e b e n e n T e i l e n das WANN, d.h. die Z e i t b e d i n g u n g e n f~r die Aktivit~ten,

und das WO, d.h. die Orte des G e s c h e h e n s wie M e B s t e l l e n

und Datenwege,

festgeiegt.

Das WIE, die A k t i v i t ~ t e n bzw. A l g o r i t h m e n

selbst, w e r d e n in e i n e m PL/I Subset beschrieben.

Beide Teile sind

Ober a b g e s t i m m t e N a h t s t e l l e n m i t e i n a n d e r verknHpft.

222

PEARL

ist eine universelle Echtzeitsprache,

Arbeitsgruppe in Deutschland, schulangeh~rige mitwirkten.

entwickelt von einer

in der sowohl Industrie- wie auch Hoch-

Sie enth~lt Anregungen aus allen drei

schon erw~hnten Sprachen und dar0ber hinaus einen sehr vollst~ndigen Komplex von Operationen

zum Programmieren paralleler Prozesse.

PEARL

selbst sollte dem Wunsche seiner Autoren und deren FSrderer entsprechend ein Sprachvorschlag licher F@rderung

fur eine Standardisierung

sein° Trotz staat-

ist jedoch noch immer nicht zu erkennen, wie anders

als Nber den Nblichen Weg von Compilerangebot und Nachfrage diesem Sprachvorschlag das Gewicht eines Standards zukommen k@nnte.

PROCOL

ist eine franz~sische Entwicklung~

ziell fur die Echtzeitanwendungen schaffen.

ein Program/niersystem spe-

auf dem ProzeB-Kontrollgebiet

Es so!l dem Programmierer

mittel anbieten wie FORTRAN dem technisch-wissenschaftlichen mierer. system

ge-

solcher Aufgaben ~hnliche HilfsProgram-

Das System umfaBt in seiner Definition schon Realzeit-Betriebs(fUr eine spezielle Anlage),

einen Compiler

(der auf die Assemb-

lerspraehe dieser Anlage zur~ckf~hrt) ~ einen Systemgenerator, gestattet,

der es

fur eine bestimmte Konfiguration ein Betriebssystem maBzu-

schneidern und einen Systemlader,

der unter anderem die Speicherbele-

gung durch residente und nicht residente Programme regelt.

Ver~leich existierender S prachvorschl~ge Der Vergleich dieser Programmiersprachen mit dem Ziel, in irgendeiner Weise zu einem einheitlichen Standardisierungsvorschlag

zu kommen,soll

anhand von nebeneinander gestellten Antworten zu einer handvoll Fragenkatalogen erfolgen.

Bisher hat die europ~ische LTPLC-Gruppe Fragenka-

taloge zu fHnf verschiedenen Themengruppen aufgestellt:

zum Komplex

TASKING, wozu alle Sprachmittel gerechnet werden, die mit der Steuerung,

Syn-

chronisation und zeitlichen Einplanung paralleler Prozesse zu tun haben; ALGORITHMISCHER TEIL, WOZU alle Sprachmittel gez~hlt werden~ die allgemein in Programmiersprachen angeboten sind zur Formulierung von Algor±thmen

jeder Art;

223

EIN- und AUSGABE, wozu neben der sogenannten Standard E/A, wie sie zum Betreiben von Schneildruckern,

Lochkarten- und Lochstreifenger~ten,

Magnetb~ndern

und -platten n~tig ist, vor allem die prozeBspezifische

E/A geh~rt.

Hier soll imgrunde jede wie auch immer geartete Elektronik p r o g r a ~ i e r bar sein, die an einen Rechner angeschlossen werden kann;

kNLAGENBESCHREIBUNG, wozu der Teil der Programmiersprachen

geh~rt, der dazu gedacht ist,

vom Compiler her eine VerknHpfung von symbolischen Namen im Programm zu anlagenbedingten

Schaltwegen und Datenendstellen

zu knHpfen;

ERFAHRUNGEN mit der Sprache, wozu allerdings nur dort Antworten erwartet werden k~nnen, wo aufgrund von Implementationen und einschl~gigen Anwendungen Erfahrungen gesammelt worden sind.

Die Fragen sind naturgem~B schneller gestellt als beantwortet.

So sind

zur Zeit vollst~ndig beantwortet nur die ersten zwei Komplexe,

zu

einem groBen Teil der dritte.

Einen Eindruck yon den Fragen selbst

und den dazu gegebenen Antworten und, soweit schon m~glich, SchluBfolgerung

eine

aus den mittels dieser Antworten angestellten Uberle-

gungen soll der Vortrag selbst vermitteln.

Literatur

Sam/net, J. E., Programming Languages,

Histo!y and Fundamentals

Englewood Cliffs, N. J., 1969 Deutscher NormenausschuB

(DNA), Hrsg., informationsverarbeitung,

DIN Taschenbuch

25, Beuth-Vertrieb,

ECMA and ANSI, Hrsg., PL/I ECMA.TCIO/ANSI.X3JI

Berlin 1972 BASIS/l,

BASIS/I-IO June 1973 Minutes of the Workshop on Standardization of Industrial Computer Languages,

Purdue Lab. for Applied Industrial Control,

Purdue University, West Lafayette, Wijngaarden A. van

(Editor), Mailloux,

Indiana USA

B. J., Peck J. E. L. and

Koster C. H. A.r Report on the Algorithmic Language ALGOL 68, Numerische Mathematik 14, 79-218

(1969)

224

Woodward P.M. and Bond S.G., ALGOL 68-R Users Guide, Ministry of Defence, London, Her Majesty's Stationery Office Ministry of Technology, Ministry of Defence

1972

(Editors), Official

Definition of CORAL 66, London, Her Majesty's St.O. Kussl V.~ PASi-Sprachbeschreibung,

1970

Brown, Boveri & Cie AG,

Mannheim 1971 Abt. ZEK-ED

(Hrsg.), BBC - PL/I - Subset Sprachbeschreibung~ Brown, Boveri & Cie AG, Mannheim 1972

Timmesfeld K.H., B. Schfirlein, P.Rieder,

K.Pfeiffer,

G.M~ller,

K.F. Kreuter, P. Holleczek, V. Haase, L. Frevert, S. Eichentopf, B. Eichenauer,

P.Elzer,

J. Brandes,

PEARL - A proposal for a process- and experiment automation realtime language, Ges. f. Kernforschung mbH, Karlsruhe, Notice Technique, 1973

Report KFK-PDV l, April 1973

Systeme Procol T2OOO, STERIA, Le Chesnay, France

(TIA/PB/MP R&f.

1 162 220/00 39 OO)

Expert Group, Tasking Comparative Study, LTPL-European Group, LTPL-E/I05,

Tandemlabor Universit~t Erlangen, April 1973

Heger, J., N.V. Jones~ K.F. Kreuter, G. Louit~ J.C. Wand~ A comperative Study of the Algorithmic Parts of the Progranting Languages ALGOL 68, CORAL 66, PASI - BBC PL/I, PEARL, PROCOL, edited by R. R~Bler, LTPL - European Group, Tandemlabor Universit~t Erlangen, November

1973

Anschrift des Verfassers: Dr.rer. ESG

-

nat.Konrad F°Kreuter

Elektronik-System GmbH

Postfach 86 0305 D-8OO0 Mfinchen 86 Germany FR

225

Al~habetisches

V e r z e i c h n i s der A u t o r e n

J .....................................

173

Barnes,

J.G.P ...................................

189

DeRemer,

F.L ....................................

78

R.W .....................................

68

Baginski,

Friday,

Friesland,

G ....................................

Grosse-Lindemann,

Koch,

34 162

K.F ....................................

KrUger,

101

H ....................................

G .........................................

Ereuter,

101

U ......................................

JGrgensen, Kastens,

C.-0 ..........................

199 219

F .......................................

25

Kupka,

I ........................................

45

Kussl,

V ........................................

199

Langmaack, Lippe,

W ........................................

13

P.-W ....................................

101

Lorenz, Nanna,

Z.

... . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . ..

78

H.-H .....................................

101

W .......................................

149

R .....................................

114

U .......................................

89 55

Niegel, Nollmann, Peters, Rohlfing,

H .....................................

Seiffert, Stirl,

*)

W.N ...................................

NcKeeman, Nagel,

I

H ..............................

H .....................................

173

P.J ......................................

101

W.T .....................................

133

N ......................................

45

Wilner, Wilsing,

*) M a n u s k r i p t werden.

konnte

vom

Verfasser

nicht

fertiggestellt