Vorlesungsskript - Institut für Programmierung und Reaktive Systeme

TECHNISCHE UNIVERSITÄT CAROLO-WILHELMINA ZU BRAUNSCHWEIG 

Vorlesungsskript 

Compilerbau 

Prof. Dr. Ursula Goltz Dr. Thomas Gehrke 

Dipl.-Inform. Malte Lochau 

1. April 2009 

Institut für Programmierung und Reaktive Systeme

Vorwort 

Das vorliegende Skript ist als Ausarbeitung der Compilerbau-Vorlesung entstanden, 

die ich seit dem Sommersemester 1992, zunächst an der Universität Hildesheim, seit 

1998 an der Technischen Universität Braunschweig halte. Die erste Version der Vorlesung 

war stark durch die Compilerbau-Vorlesung Prof. Dr. Klaus Indermark, die 

ich in den 80’er Jahren an der RWTH Aachen als Mitarbeiterin betreuen durfte, 

beeinflusst. Sie basiert außerdem zu großen Teilen auf dem klassischen ” Drachenbuch“ 

[Aho08] von Aho et. al. Sehr hilfreich bei der Weiterentwicklung der Vorlesung 

war das zwischenzeitlich erschienene Buch von Reinhard Wilhelm und Dieter Maurer 

[WM96]. 

Darüber hinaus haben im Laufe der Jahre viele Beteiligte zur Ausarbeitung und Weiterentwicklung 

dieses Skripts beigetragen, denen ich an dieser Stelle danken möchte. 

Zunächst danke ich Dr. Michaela Huhn und Dr. Peter Niebert, die mich bei der Konzeption 

der Vorlesung in Hildesheim hervorragend unterstützt haben. Besonderer 

Dank gebührt meinen Mitautoren Dr. Thomas Gehrke und Malte Lochau, die dieses 

Skript mit hoher Selbstständigkeit bearbeitet haben. Dr. Werner Struckmann und 

Tilo Mücke haben durch Ergänzungen und hilfreiche Hinweise beigetragen. Jochen 

Kamischke hat uns als studentische Hilfskraft sehr gut unterstützt. Die Studierenden, 

die diese Vorlesung in den vergangenen Jahren gehört haben, haben durch ihre aktive 

Teilnahme ebenfalls zur Weiterentwicklung des Skripts beigetragen; auch Ihnen 

gebührt mein herzlicher Dank. 

Braunschweig, den 5. März 2009 

Ursula Goltz 

i

Inhaltsverzeichnis 

Verzeichnis der Abbildungen v 

Verzeichnis der Tabellen vii 

Listings viii 

1 Einführung 1 

1.1 Inhalte und Gliederung . . . . . . . . . . . . . . . . . . . . . . . . . . 1 

1.2 Höhere Programmiersprachen . . . . . . . . . . . . . . . . . . . . . . 2 

1.3 Implementierung von Programmiersprachen . . . . . . . . . . . . . . 3 

1.3.1 Interpreter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 

1.3.2 Compiler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 

1.3.3 Virtuelle Maschinen als Zielplattform . . . . . . . . . . . . . . 4 

1.4 Umgebung eines Compilers . . . . . . . . . . . . . . . . . . . . . . . . 5 

1.5 Aufbau eines Compilers . . . . . . . . . . . . . . . . . . . . . . . . . 7 

1.5.1 Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 

1.5.2 Synthese . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 

1.5.3 Front-End, Back-End . . . . . . . . . . . . . . . . . . . . . . . 12 

1.5.4 Läufe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 

2 Lexikalische Analyse 14 

2.1 Terminologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 

2.2 Reguläre Sprachen und endliche Automaten . . . . . . . . . . . . . . 15 

2.2.1 Reguläre Sprachen . . . . . . . . . . . . . . . . . . . . . . . . 16 

2.2.2 Reguläre Ausdrücke . . . . . . . . . . . . . . . . . . . . . . . . 16 

2.2.3 Endliche Automaten . . . . . . . . . . . . . . . . . . . . . . . 18 

2.2.4 Reguläre Definitionen . . . . . . . . . . . . . . . . . . . . . . . 27 

2.3 Sieber . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 

2.4 Fehlerbehandlung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 

3 Syntaktische Analyse 35 

3.1 Kontextfreie Grammatiken . . . . . . . . . . . . . . . . . . . . . . . . 35 

3.1.1 Kontextfreie Grammatiken . . . . . . . . . . . . . . . . . . . . 36 

3.1.2 Ableitungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 

3.1.3 Strukturbäume . . . . . . . . . . . . . . . . . . . . . . . . . . 40 

iii

Inhaltsverzeichnis 

3.1.4 Mehrdeutige Grammatiken . . . . . . . . . . . . . . . . . . . . 42 

3.2 Konstruktion von Parsern . . . . . . . . . . . . . . . . . . . . . . . . 46 

3.2.1 Kellerautomat . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 

3.3 Top-Down-Syntaxanalyse . . . . . . . . . . . . . . . . . . . . . . . . . 49 

3.3.1 LL(k)-Grammatiken . . . . . . . . . . . . . . . . . . . . . . . 51 

3.3.2 Transformierung von Grammatiken . . . . . . . . . . . . . . . 59 

3.3.3 Erweiterte kontextfreie Grammatiken . . . . . . . . . . . . . . 67 

3.3.4 Fehlerbehandlung bei der Top-Down-Analyse . . . . . . . . . . 75 

3.4 Bottom-Up-Syntaxanalyse . . . . . . . . . . . . . . . . . . . . . . . . 80 

3.4.1 LR(k)-Grammatiken . . . . . . . . . . . . . . . . . . . . . . . 84 

3.4.2 Fehlerbehandlung bei der Bottom-Up-Analyse . . . . . . . . . 113 

3.5 Parser Generatoren . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 

4 Semantische Analyse 118 

4.1 Attributierte Grammatiken . . . . . . . . . . . . . . . . . . . . . . . . 119 

4.2 Typüberprüfung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128 

4.2.1 Typsysteme . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 

4.2.2 Gleichheit von Typausdrücken . . . . . . . . . . . . . . . . . . 135 

4.2.3 Typumwandlungen . . . . . . . . . . . . . . . . . . . . . . . . 137 

5 Zwischencode-Erzeugung 141 

5.1 Abstrakte Keller-Maschinen . . . . . . . . . . . . . . . . . . . . . . . 142 

5.1.1 Syntaxbäume . . . . . . . . . . . . . . . . . . . . . . . . . . . 143 

5.1.2 Zwischencode für die Keller-Maschine . . . . . . . . . . . . . . 147 

5.1.3 Befehle zur Steuerung des Kontrollflusses . . . . . . . . . . . . 147 

5.2 Drei-Adreß-Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151 

5.2.1 Übersetzung von Syntaxbäumen in Drei-Adreß-Code . . . . . 153 

5.2.2 Übersetzung in Drei-Adreß-Code unter Verwendung von attributierten 

Grammatiken . . . . . . . . . . . . . . . . . . . . . . 155 

5.3 Vergleich der beiden Arten von Zwischencode . . . . . . . . . . . . . 157 

Literaturverzeichnis 158 

iv

Verzeichnis der Abbildungen 

1.1 Umgebung eines Compilers. . . . . . . . . . . . . . . . . . . . . . . . 6 

1.2 Phasen eines Compilers. . . . . . . . . . . . . . . . . . . . . . . . . . 7 

1.3 Übersetzung einer Zuweisung. . . . . . . . . . . . . . . . . . . . . . . 9 

1.4 Parse-Baum der Zuweisung. . . . . . . . . . . . . . . . . . . . . . . . 10 

2.1 Interaktion zwischen Scanner und Parser. . . . . . . . . . . . . . . . . 14 

2.2 Beispiel eines Übergangsgraphen. . . . . . . . . . . . . . . . . . . . . 20 

2.3 Konstruktion eines NEA zu einem regulärem Ausdruck. . . . . . . . . 21 

2.4 Beispiel einer NEA-Konstruktion. . . . . . . . . . . . . . . . . . . . . 21 

2.5 Beispiel zur Potenzmengenkonstruktion. . . . . . . . . . . . . . . . . 24 

2.6 DEA mit minimaler Zustandsmenge. . . . . . . . . . . . . . . . . . . 26 

2.7 Beispiel zur Minimalisierung. . . . . . . . . . . . . . . . . . . . . . . . 26 

2.8 Übergangsgraphen für die Symbole des Beispiels. . . . . . . . . . . . 31 

2.9 Analyse eines Programmausschnitts. . . . . . . . . . . . . . . . . . . 33 

3.1 Interaktion zwischen Scanner, Parser und restlichem Front-End. . . . 35 

3.2 Beispiel eines Strukturbaums. . . . . . . . . . . . . . . . . . . . . . . 41 

3.3 Konstruktion eines Strukturbaums. . . . . . . . . . . . . . . . . . . . 42 

3.4 Verschiedene Strukturbäume zu einem Satz. . . . . . . . . . . . . . . 43 

3.5 Mögliche Strukturbäume des “dangling else”-Problems. . . . . . . . . 44 

3.6 Lösung des “dangling else”-Problems. . . . . . . . . . . . . . . . . . . 45 

3.7 Schema eines Kellerautomaten. . . . . . . . . . . . . . . . . . . . . . 47 

3.8 Konstruktion des Strukturbaums anhand der Ausgabe des Parsers. . . 52 

3.9 Fehlerhafte Konstruktion eines Strukturbaums für die Eingabe a. . . 56 

3.10 Transformation in rechtsrekursive Grammatik. . . . . . . . . . . . . . 61 

3.11 Beispiel einer regulären Ableitung. . . . . . . . . . . . . . . . . . . . 69 

3.12 Übergangsgraphen für arithmetische Ausdrücke. . . . . . . . . . . . . 71 

3.13 Übergangsgraphen für Pascal-Typen. . . . . . . . . . . . . . . . . . . 73 

3.14 Beispiel eines recursive descent-Parsers. . . . . . . . . . . . . . . . . . 74 

3.15 Aufrufgraph einer recursive descent-Syntaxanalyse. . . . . . . . . . . 75 

3.16 Erzeugung eines Strukturbaums für einen arithmetischen Ausdruck. . 82 

3.17 Beispiel eines charakteristischen endlichen Automaten . . . . . . . . . 90 

3.18 Beispiel eines LR-DEA. . . . . . . . . . . . . . . . . . . . . . . . . . . 94 

3.19 Struktur einer LR(1)-Parse-Tabelle. . . . . . . . . . . . . . . . . . . . 104 

v

Verzeichnis der Abbildungen 

vi 

3.20 Zustandsmenge des LR-DEA der Grammatik zur Beschreibung der 

C-Zuweisung aus Beispiel 43. . . . . . . . . . . . . . . . . . . . . . . 106 

3.21 Zustandsmenge des charakteristischen endlichen Automaten mit LR(1)- 

Items zur Grammatik aus Beispiel 43. . . . . . . . . . . . . . . . . . . 107 

3.22 Charakteristischer endlicher LR(1)-Automat zur Grammatik aus Beispiel 

43. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 

3.23 Zustandsmenge des charakteristischen endlichen Automaten mit SLR(1)- 

Items für die Grammatik aus Beispiel 43. . . . . . . . . . . . . . . . . 110 

3.24 Zustandsmenge des charakteristischen endlichen Automaten mit LALR(1)- 

Items für die Grammatik aus Beispiel 43. . . . . . . . . . . . . . . . . 111 

3.25 Charakteristischer endlicher LR(1)-Automat zur Grammatik aus Beispiel 

43. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 

4.1 Beispiel eines attributierten Strukturbaums. . . . . . . . . . . . . . . 119 

4.2 Synthetische und inherite Attribute. . . . . . . . . . . . . . . . . . . . 120 

4.3 Berechnung von Typinformationen im Strukturbaum. . . . . . . . . . 121 

4.4 Attributierter Strukturbaum zur Analyse einer Binärzahl. . . . . . . . 123 

4.5 Attributierter Strukturbaum zur Analyse einer Binärzahl mit inheritem 

Attribut. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124 

4.6 Darstellung der direkten Abhängigkeiten zwischen Attributvorkommen.126 

4.7 Beispiel eines Abhängigkeitsgraphen. . . . . . . . . . . . . . . . . . . 127 

4.8 “Verklebter” Abhängigkeitsgraph. . . . . . . . . . . . . . . . . . . . . 127 

4.9 Semantische Regeln für Beispielsprache. . . . . . . . . . . . . . . . . . 133 

4.10 Attributierter Strukturbaum für ein Beispielprogramm. . . . . . . . . 133 

4.11 Attributierter Strukturbaum für ein fehlerhaftes Beispielprogramm. . 134 

4.12 Funktion zur Überprüfung, ob zwei Typausdrücke identisch sind. . . . 135 

4.13 Attributierter Strukturbaum einer Zuweisung. . . . . . . . . . . . . . 139 

4.14 Attributierter Strukturbaum einer Zuweisung mit Attributabhängigkeiten. 

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 

4.15 Attributierter Strukturbaum einer Zuweisung mit Typfehler. . . . . . 140 

5.1 Einordnung der Zwischencode-Erzeugung. . . . . . . . . . . . . . . . 141 

5.2 Syntaxbaum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144 

5.3 Konstruktion eines Syntaxbaums aus Postfix-Notation. . . . . . . . . 145 

5.4 Auswertung eines Postfix-Ausdrucks mit Hilfe eines Stacks. . . . . . . 146 

5.5 Attributierter Strukturbaum mit Zwischencode. . . . . . . . . . . . . 148 

5.6 Attributierter Strukturbaum einer verschachtelten if-Anweisung. . . . 152 

5.7 Syntaxbaum mit temporären Namen. . . . . . . . . . . . . . . . . . . 154 

5.8 Syntaxbaum mit Attributen für die Erzeugung von Drei-Adreß-Code. 156

Verzeichnis der Tabellen 

2.1 Beispiele für Symbole, Muster und Lexeme. . . . . . . . . . . . . . . 15 

2.2 Übergangsrelation ∆ in Tabellenform. . . . . . . . . . . . . . . . . . . 20 

2.3 Reguläre Ausdrücke und die dazugehörigen Symbole und Attributwerte. 29 

3.1 Beispielableitung eines Top-Down-Parsers. . . . . . . . . . . . . . . . 50 

3.2 Beispiel einer Parse-Tabelle. . . . . . . . . . . . . . . . . . . . . . . . 64 

3.3 Parse-Tabelle für dangling-else-Grammatik. . . . . . . . . . . . . . . . 67 

3.4 Für Fehlerbehandlung modifizierte Parse-Tabelle. . . . . . . . . . . . 77 

3.5 Beispiel einer Ableitung mit Fehlerbehandlung. . . . . . . . . . . . . 78 

3.6 Beispielableitung eines Bottom-Up-Parsers. . . . . . . . . . . . . . . . 83 

vii

Listings 

viii 

NEA nach DEA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 

DEA Minimalisierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 

Berechnung von FIRST 1–Mengen . . . . . . . . . . . . . . . . . . . . . . 57 

Berechnung von FOLLOW 1–Mengen . . . . . . . . . . . . . . . . . . . . . 58 

Transformation einer linksrekursiven in eine rechtsrekursive Grammatik . . 60 

Linksfaktorisierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 

Konstruktion der Parse–Tabelle zu einer Grammatik . . . . . . . . . . . . 63 

Deterministische Top–Down–Analyse mit Parse–Tabelle . . . . . . . . . . . 65 

Konstruktion der FIRST–und FOLLOW–Mengen einer ELL(1)–Grammatik 69 

Beispiel eines recursive descent–Parsers . . . . . . . . . . . . . . . . . . . . 74 

LR–DEA–Konstruktion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 

Algorithmus LR(1)–GEN . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 

Konstruktion der LR(1)–action–Tabelle . . . . . . . . . . . . . . . . . . . . 104 

LR(1)–Parse–Algorithmus . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 

Konstruktion der SLR(1)–action–Tabelle . . . . . . . . . . . . . . . . . . . 109 

Ueberpruefung ob zwei Typausdruecke identisch sind . . . . . . . . . . . . 135

1 Einführung 

1.1 Inhalte und Gliederung 

Die Techniken zur Konstruktion von Übersetzern (Compiler) als der altehrwürdigen 

Disziplin der Informatik sind unverändert allgegenwärtig. Wie kaum ein anderes 

Gebiet der Informatik werden beim Compilerbau Themen aus Theorie und Praxis 

miteinander verbunden. Auf der einen Seite bilden Automatentheorie und formale 

Sprachen das theoretische Fundament bei der Implementierung von Programmiersprachen. 

Zugleich gehören aber auch praktische Fragestellungen beim Entwurf und 

der Entwicklung von Programmiersprachen für konkrete Aufgabenstellungen zu diesem 

Beschäftigungsfeld. Schließlich muss sich der Compilerbauer auch mit den Ressourcen, 

Befehlssätzen etc. unterschiedlichster Rechnerarchitekturen möglicher Zielplattformen 

auseinander setzen. 

Auch bei aktuellen Themen und Problemstellungen der Informatik kommt man an 

Techniken des Compilerbaus nicht vorbei. Dazu zählen Themen wie virtuelle Maschinen, 

Parallelisierung, Speicherlokalität und Programmanalyse und -optimierung. 

Das vorliegende Skript ist in zwei Teile gegliedert. Der erste Teil befasst sich mit den 

Teilen des Compilers, die als Front-End bezeichnet werden. Dazu zählen alle Phasen 

des Übersetzungsvorgangs einer Eingabesprache, die unabhängig von der Zielsprache 

und Ausführungsplattform für übersetzte Programme erfolgen. Dazu zählen insbesondere 

die Analysephasen zur Überprüfung der Korrektheit des Eingabeprogrammes 

sowie die im Rahmen der einzelnen Übersetzungsschritte erzeugten Zwischendarstellungen 

des Eingabeprogrammes. 

Nach dem einführenden Kapitel, das die Grundbegriffe des Übersetzerbaus einführt, 

folgen aufeinander aufbauend die ausführliche Einführung der Konzepte der lexikalischen, 

syntaktischen und (statischen) semantischen Analyse. Die Vorgehensweise 

in den einzelnen Phasen wird jeweils durch Beispiele veranschaulicht, so zum Beispiel 

die Typüberprüfung im Rahmen der semantischen Analyse. Eine systematische 

Einführung in die theoretischen Grundlagen von Typsystemen erfolgt dann im zweiten 

Teil des Skripts. Als Abschluss des ersten Teils werden verschiedene Techniken 

der Zwischencode-Erzeugung beschrieben, die den vorbereitenden Schritt für die anschließende 

Code-Generierung durch das Back-End darstellen. 

Der zweite Teil des Skripts ist dem Back-End des Compilers gewidmet, also den 

Zielplattform-spezifischen Phasen, in denen die Synthese des Zielprogrammes aus 

dem Quellprogramm erfolgt. Der Schwerpunkt wird in diesem Teil auf der Überset-

1 Einführung 

zung objektorientierter Programmiersprachen liegen, deren statische und dynamische 

Eigenschaften im Detail untersucht werden. Als exemplarische Zielplattform werden 

abstrakte bzw. virtuelle Maschine betrachtet. Die theoretischen Grundlagen werden 

dann ausführlich an einer konkreten Programmiersprache, der objektorientierten 

Sprache Java, verdeutlicht. Den Abschluss bilden Optimierungstechniken für Übersetzer, 

wobei sowohl allgemeine Ansätze, als auch speziell objektorientierte Ansätze 

beschrieben werden. 

1.2 Höhere Programmiersprachen 

In der Anfangszeit der Informatik wurde die Programmierung von Rechnern in der 

jeweiligen Maschinensprache des entsprechenden Rechners vorgenommen. Aufgrund 

der Rechnerorientierung dieser Sprachen war der Entwurf sowie die nachfolgende 

Anpassung und Änderung des Programmcodes äußerst aufwendig und mit hohen 

Kosten verbunden. Speicherzellen mußten direkt über ihre jeweiligen Adressen angesprochen 

werden. Wurden nachträglich Änderungen am Programm vorgenommen, 

mußten diese Adressen “von Hand” angepaßt werden. 

Eine erste Verbesserung wurde durch die Einführung der Assemblersprachen erzielt. 

Den Befehlen der Maschinensprache wurden kurze Buchstabenfolgen, sogenannte 

Mnemonics 1 , zugeordnet, die die Lesbarkeit von Programmtexten erhöhen. Das 

Programm zur Generierung des zu einem Assemblertext gehörenden Maschinenprogramms, 

ebenfalls Assembler genannt, erlaubte eine rudimentäre Überprüfung des 

Programmtextes auf Fehler. Außerdem wurde durch die Möglichkeit zur Vergabe 

symbolischer Adressen (labels) die Pflege von Programmen erleichtert. 

Trotz der Überlegenheit der Assemblersprachen gegenüber den Maschinensprachen 

besitzt die Programmerstellung mittels Assembler eine Reihe bedeutender Nachteile. 

Durch die direkte Zuordnung von Mnemonics zu Maschinenbefehlen ist der Abstraktionsgrad 

von Programmen gering, so daß sich die Programmierung immer noch an 

der Maschine und nicht am konkreten Problem orientieren muß. Assemblerprogramme 

sind aufgrund ihres Mangels an Strukturelementen nur schwer verständlich, was 

eine erschwerte Wartbarkeit von Programmen zur Folge hat. Durch den Mangel an 

Datenstrukturen ist die Handhabung der Daten eines Programms aufwendig. Außerdem 

sind Assemblerprogramme nur auf einem Maschinentyp einsetzbar, so daß 

Portierungen von Programmen auf andere Maschinentypen mit anderer Maschinensprache 

i. allg. nicht möglich sind. 

Um die Nachteile der Assemblersprachen zu vermeiden und um eine problembezogene 

Programmierung zu unterstützen, wurden die höheren Programmiersprachen eingeführt. 

Diese Sprachen abstrahieren von den Eigenschaften der verwendeten Rechner. 

Kontrollstrukturen wie z.B. Schleifen und Rekursion erlauben eine Steuerung 

2 

1 Mnemonik ist die Kunst, das Gedächtnis durch Hilfsmittel zu unterstützen.

1.3 Implementierung von Programmiersprachen 

des Programmflusses ohne die Verwendung von Sprungbefehlen. Das Konzept der 

Variablen und der Datentypen entlastet den Programmierer von der aufwendigen 

Speicherverwaltung. Durch den Abstraktionsgrad wird zudem die Portierung von 

Programmen auf andere Rechnerarchitekturen erleichtert. 

1.3 Implementierung von Programmiersprachen 

Um Programme einer höheren Programmiersprache auf einem Rechner ausführen zu 

können, muß diese Sprache auf diesem Rechner verfügbar gemacht (implementiert) 

werden. Die dazu existierenden Konzepte werden in zwei Klassen eingeteilt. 

1.3.1 Interpreter 

Ein Interpreter IL zur einer Programmiersprache L ist ein Programm, das als Eingabe 

ein Programm pL der Sprache L und eine Eingabefolge e erhält und eine Ausgabefolge 

a errechnet. Da bei der Interpretation von pL auch Fehler auftreten können, läßt sich 

die Funktionalität des Interpreters darstellen als 

IL : L × D ∗ → D ∗ ∪ {error}, 

wenn sowohl Eingabe- wie auch Ausgabedaten aus einem gemeinsamen Bereich D 

stammen. Die Ausführung des Programms pL mit Eingabefolge e und Ausgabefolge 

a ist durch die Gleichung 

IL(pL,e) = a 

beschrieben. 

Die Arbeitsweise eines Interpreters ist gekennzeichnet durch eine gleichzeitige Bearbeitung 

des Programms pL und der Eingabe e. Dies führt dazu, daß der Interpreter 

bei jeder, also auch bei wiederholter, Ausführung eines Programmkonstrukts zuvor 

das Konstrukt analysieren muß. Daher kann der Interpreter auch keine globalen Informationen, 

etwa zur Optimierung der Speicherverwaltung, über pL verwenden. 

1.3.2 Compiler 

Um die aus der lokalen Sicht eines Interpreters auf das auszuführende Programm resultierenden 

Ineffizienzen zu vermeiden, werden beim Compiler die Verarbeitung des 

Programms und der Eingabe nacheinander durchgeführt. Zuerst wird das Programm 

pL ohne die Berücksichtigung von Eingabedaten analysiert und in eine andere Form 

überführt. Diese erlaubt die effizientere Ausführung des Programms mit beliebigen 

Eingabefolgen, ohne daß die Analyse und die Überführung des Programms wiederholt 

werden müssen. 

3

1 Einführung 

Wir nennen unsere zu übersetzende Sprache L im folgenden Quellsprache. Die Übersetzung 

besteht in der Überführung eines Programms pL der Quellsprache in ein 

Programm pM, wobei M die Maschinen- oder die Assemblersprache eines konkreten 

oder abstrakten Rechners ist. Wir nennen pM Zielprogramm und folglich M die 

Zielsprache des Übersetzers. 

Nach der Übersetzung wird das erzeugte Programm pM zur Laufzeit mit der Eingabefolge 

e ausgeführt. Dabei gehen wir davon aus, daß pM mit der Eingabe e die 

Ausgabe a erzeugt, wenn ein Interpreter für L mit IL(pL,e) = a dieselbe Ausgabe 

erzeugt. Wenn wir die Maschine, deren Maschinensprache unsere Zielsprache M ist, 

als Interpreter IM für M auffassen, so muß gelten: 

wenn IL(pL,e) = a, dann IM(pM,e) = a. 

Neben der Generierung des Zielprogramms wird während der Übersetzung eines Programms 

eine umfassende Überprüfung auf Fehler des zu analysierenden Programmtextes 

vorgenommen. Durch diese globale Analyse können manche Fehler bereits vor 

der Ausführung des Programms gefunden werden, während dies beim Interpreter aufgrund 

seiner lokalen Sicht auf den Programmtext erst zur Laufzeit geschehen kann. 

Der Compiler erkennt nur Fehler eines Programmes, die von der konkreten Eingabe 

während eines Programmlaufs unabhängig sind. Hierzu gehören neben syntaktischen 

Fehlern auch semantische Fehler, z.B. Zugriffe auf nichtdeklarierte Variablen. Fehler, 

die aus der Eingabe e resultieren, können auch beim Compiler erst zur Laufzeit des 

Zielprogramms pM entdeckt werden. 

1.3.3 Virtuelle Maschinen als Zielplattform 

Bei der klassischen Implementierung einer Programmiersprache auf einer Zielplattform 

sind wir bisher sowohl bei der Verwendung eines Interpreters als auch eines 

Compilers von der Maschinensprache des realen Rechners als Zielsprache ausgegangen. 

Dieser Ansatz hat mehrere Nachteile: 

• Der Compiler-Entwickler muss für eine Vielzahl unterschiedlicher Instruktionssätze 

von Prozessoren entsprechende Back-Ends (siehe unten) zur Verfügung 

stellen. 

• Der Compiler-Entwickler möchte für eine effiziente Code-Erzeugung auf Befehle 

zurückgreifen, die eventuell nicht im Instruktionssatz enthalten sind. Das 

gilt insbesondere für die Umsetzung spezieller Konstrukte der Quellsprache, 

beispielsweise zur Behandlung von Ausnahmen. 

• Insbesondere möchte der Entwickler für die Übersetzung von Programmen entwickelte 

Ansätze trotz sich ändernder Instruktionssätze und Rechnerarchitekturen 

gleich bleibende Rahmenbedingungen vorfinden. 

4

1.4 Umgebung eines Compilers 

Aus diesen Gründen wird bei der Implementierung neuerer Programmiersprachen 

zunehmend dazu übergegangen, den Instruktionssatz einer idealisierten abstrakten 

oder virtuellen Maschine (VM) als Zielsprache des Compilers einzuführen. Die so 

definierte zusätzliche Abstraktionsschicht auf der Zielplattform hat mehrere Vorteile: 

• Die Implementierung der virtuellen Maschine für eine spezifische Plattform 

kann unabhängig von der Entwicklung des Compilers vorgenommen werden, 

solange beides mit Hinblick auf einen festen Instruktionssatz der VM erfolgt. 

• Für die VM erzeugte Code ist auf jedem System lauffähig, auf dem die VM 

implementiert ist (Portierbarkeit). 

• Der Befehlssatz der VM kann passend zu Paradigmen und Konstrukten der 

Quellsprache gewählt werden und erlaubt so eine effiziente Übersetzung der 

Quellprogramme. Beispiel: Der Java Bytecode (JBC) als Instruktionssatz der 

Java Virtual Machine (JVM) beinhaltet spezielle Befehle zum Umgang mit 

Objekten, da die Quellsprache Java objektorientiert ist. 

• Der durch den Compiler erzeugte Code wird nicht direkt auf dem Zielsystem 

ausgeführt, sondern auf einer Zwischenschicht, wodurch eine sicherere Ausführung 

gewährleistet werden kann (Sand-Boxing). 

Somit kann der Einsatz einer virtuellen Maschine für die Implementierung einer Programmiersprache 

als Kombination beider zuvor vorgestellten Ansätze gesehen werden: 

1. Die Übersetzung des Quellprogramms in ein Programm für die virtuelle Maschine 

erfolgt durch einen Compiler. 

2. Die virtuelle Maschine ist ein Interpreter für das durch den Compiler erzeugte 

Zielprogramm. 

In zweiten Teil der Vorlesung werden wir uns ausführlich mit den Konzepten virtueller 

Maschinen beschäftigen. 

1.4 Umgebung eines Compilers 

Zur Umgebung eines Compilers gehören i. allg. weitere Programme, die für die Übersetzung 

und die Ablauffähigkeit eines Programms benötigt werden (Abbildung 1.1 

[ASU99]). 

Am Beginn des Übersetzungsprozesses steht ein “rohes” Quellprogramm. Dieses 

Quellprogramm enthält neben dem eigentlichen Programm zusätzliche Meta-Anweisungen, 

die beschreiben, wie das Quellprogramm vor der Übersetzung mit dem Compiler 

modifiziert werden soll. Dabei kann es sich z.B. um die Definition von Makros 

(z.B. #define in C [KR90]), um die Generierung zusätzlicher Befehle zur Fehlersuche 

oder um das Einfügen weiterer Quelltexte (z.B. \include in L ATEX [Kop02]) handeln. 

Diese Modifikationen des Quelltextes werden von einem sogenannten Präprozessor 

5

1 Einführung 

"rohes" Quellprogramm 

Präprozessor 

Quellprogramm 

Compiler 

Assemblerprogramm 

Assembler 

relokatibler Maschinencode 

Lader / Binder 

ausführbarer Maschinencode 

Abbildung 1.1: Umgebung eines Compilers. 

vorgenommen. 

Nach der Behandlung des Quelltextes durch den Präprozessor kann der Compiler das 

Zielprogramm erzeugen. Wie zuvor erwähnt, handelt es sich bei dem Zielprogramm 

entweder um ein Maschinenspracheprogramm bzw. einen Assemblertext. Im zweiten 

Fall muß der Assemblertext nun in einem zusätzlichen Schritt durch den Assembler 

in Maschinencode übersetzt werden. Oft wird heutzutage vom Compiler statt des 

Assemblertextes ein C-Programm erzeugt, welches vom C-Compiler weiterverarbeitet 

wird. 

Der vom Compiler erzeugte Maschinencode ist i. allg. noch nicht ausführbar, da es 

sich um sogenannten relokatiblen Code handelt. In diesem Code sind die Sprungadressen 

noch nicht festgelegt, so daß der Code im Speicher frei verschiebbar ist. 

Außerdem müssen die Bibliotheken des jeweiligen Übersetzers noch zum erzeugten 

Maschinencode hinzugefügt werden. Diese Bibliotheken enthalten z.B. die Ein- und 

Ausgaberoutinen der Programme (z.B. das Modul InOut in Modula-2 [Wir97]) sowie 

weitere Routinen, die zur Laufzeit eines Programmes benötigt werden. Es gibt zwei 

Verfahren zur Einbindung der Bibliotheken in ein Programm. Der Binder faßt den relokatiblen 

Maschinencode und den Code der Bibliotheken zu einem neuen Programm 

zusammen und ersetzt dabei die abstrakten Programmadressen des relokatiblen Codes 

durch die statischen Adressen der Unterprogramme der Bibliotheken. Dieses erzeugte 

Programm ist ohne die Unterstützung weiterer Programme ausführbar. Der 

6

Symboltabellenverwaltung 

Quellprogramm 

lexikalische 

Analyse 

syntaktische 

Analyse 

semantische 

Analyse 

Zwischencodeerzeugung 

Codeoptimierung 

Codeerzeugung 

Zielprogramm 

1.5 Aufbau eines Compilers 

Analyse 

Fehlerbehandlung 

Synthese 

Abbildung 1.2: Phasen eines Compilers. 

Lader lädt hingegen den relokatiblen Code und den Code der benötigten Bibliotheken 

in den Hauptspeicher und ersetzt die abstrakten Adressen dort dynamisch. Aus 

diesem Grund muß der Lader bei jedem Aufruf des Zielprogramms verwendet werden. 


Die Aufgabe eines Compilers läßt sich zunächst in zwei grundlegende Teilaufgaben 

zerlegen (Abbildung 1.2): die Analyse des Quellprogramms und die Synthese des 

Zielprogramms. Beide Aufgaben werden in einer Reihe von Phasen bearbeitet. 

1.5.1 Analyse 

In den Analysephasen wird das Quellprogramm in seine Bestandteile zerlegt. Dabei 

wird eine Überprüfung auf statische (also von der konkreten Eingabe eines Programmablaufs 

unabhängige) Korrektheit des zu analysierenden Programmtextes vorgenommen. 

Enthält das Programm erkennbare Fehler, werden entsprechende Fehler- 

7

1 Einführung 

meldungen an den Benutzer ausgegeben. Weiterhin wird eine Zwischendarstellung 

des Programms erzeugt, die nur noch die für die Synthesephasen benötigten Informationen 

des Programmtextes enthält. 

Im folgenden erläutern wir die Analysephasen aus Abbildung 1.2 [ASU99] an der 

Übersetzung der Zuweisung 

position := initial + rate ∗ 60. 

Dabei nehmen wir an, daß die Variablen position, initial und rate als Fließkomma- 

Variablen deklariert sind. 

Lexikalische Analyse (scanning): Die lexikalische Analyse dient der Zerlegung des 

Zeichenstroms der Eingabe in Symbole. Die Zuweisung wird dabei in folgende Symbole 

zerlegt: 

1. Bezeichner (position) 

2. Zuweisungssymbol 

3. Bezeichner (initial) 

4. Additionssymbol 

5. Bezeichner (rate) 

6. Multiplikationssymbol 

7. Konstante (60) 

Wird als Symbol ein Bezeichner erkannt, wird dieser Bezeichner in die Symboltabelle 

des Compilers eingetragen. Jedem Bezeichner wird eine eindeutige Nummer 

zugewiesen, in unserem Beispiel der Einfachheit halber gemäß der Reihenfolge des 

Auftretens im Quellprogramm. An die nachfolgenden Phasen wird nicht mehr der 

Bezeichner selbst, sondern die ihm zugeordnete Nummer weitergegeben (in Abbildung 

1.3 [ASU99] ist während der lexikalischen Analyse position durch id1 ersetzt 

worden, initial durch id2 und rate durch id3). 

Das Teilprogramm, das die lexikalische Analyse des Quelltextes durchführt, wird 

Scanner genannt. 

Syntaktische Analyse (parsing): In der syntaktischen Analyse werden Gruppen 

von Symbolen mit hierarchischer Struktur erkannt. Die Quellsprache wird durch die 

Regeln einer kontextfreien Grammatik definiert. Anhand der Produktionen dieser 

Grammatik wird die von der lexikalischen Analyse gelieferte Symbolfolge auf Korrektheit 

überprüft. Dabei wird ein sogenannter Strukturbaum (parse-tree) erzeugt, 

der die Analyse des Programmtextes gemäß den Regeln der Grammatik darstellt. 

Für die Analyse der Zuweisung nehmen wir die folgende kontextfreie Grammatik an 

(kursiv gedruckte Wörter sind Nichtterminalsymbole): 

8

id1 

id1 

position := initial + rate * 60 

lexikalische Analyse 

id1 := id2 + id3 ∗ 60 

syntaktische Analyse 

:= 

✟ ❛ 

✟ 

❛❛ 

✘✘ 

+ 

✘ �� 

id2 

✦✦* 

❳❳❳ ✦ id3 

semantische Analyse 

:= 

60 

✟✟✟ ❳❳❳ + 

✟ ❳❳❳❳ 

✟ 

✟ 

✟ * 

id2 

❛❛❛❛ 

✟ 

✟ 

id3 

inttoreal 

Zwischencode-Erzeugung 

temp1 := inttoreal(60) 

temp2 := id3 * temp1 

temp3 := id2 + temp2 

id1 := temp3 

Code-Optimierung 

temp1 := id3 * 60.0 

id1 := id2 + temp1 

Code-Generierung 

MOVF id3, R2 

MULF #60.0, R2 

MOVF id2, R1 

ADDF R2, R1 

MOVF R1, id1 

60 

1 

2 

3 


Symboltabelle 

position 

initial 

rate 

Abbildung 1.3: Übersetzung einer Zuweisung. 

... 

... 

... 

9

1 Einführung 

✧ 

✧ ▲ ❵❵❵❵❵❵❵❵❵❵ 

▲ 

✏✏❵❵❵❵❵❵❵❵ 

✏✏ 

✏ 

✟ 

✟ 

✟ ❆ Zuweisung 

Bezeichner 

position 

:= Ausdruck 

❚ 

❚ 

Ausdruck + Ausdruck 

❳❳❳❳❳❳ ❆ 

Bezeichner Ausdruck * Ausdruck 

initial 

Bezeichner Zahl 

rate 

Abbildung 1.4: Parse-Baum der Zuweisung. 

Zuweisung → Bezeichner := Ausdruck 

Ausdruck → Bezeichner | Zahl | 

Ausdruck + Ausdruck | 

Ausdruck * Ausdruck 

Der Strukturbaum der Zuweisungsanweisung gemäß dieser Grammatik ist in Abbildung 

1.4 dargestellt. 

Der Strukturbaum enthält neben den Terminalsymbolen der Eingabe auch die Nichtterminalsymbole 

der Grammatik, die bei der Ableitung der Eingabe verwendet wurden. 

Diese Nichtterminalsymbole werden in den weiteren Phasen des Compilers nicht 

mehr benötigt. Daher wird als Endprodukt der syntaktischen Analyse ein Syntaxbaum 

erzeugt, wie er in Abbildung 1.3 dargestellt ist 2 . 

Das Teilprogramm zur syntaktischen Analyse heißt Parser. 

Semantische Analyse: Nach der Überprüfung auf syntaktische Korrektheit des 

Programms wird in der semantischen Analyse die “statische” Semantik des Quellprogramms 

analysiert. “Statisch” bedeutet in diesem Zusammenhang, daß die semantischen 

Merkmale untersucht werden, die nicht von den Eingabedaten abhängig 

und daher für alle dynamischen Ausführungen gleich sind. Zur semantischen Analyse 

gehören die Überprüfung auf korrekte Typisierung, die Einhaltung von Gültigkeitsbereichen 

und eventuelle Typanpassungen. Während der semantischen Analyse werden 

die Bezeichner in der Symboltabelle mit Attributen versehen. Hierzu gehören z.B. der 

Variablentyp und der Gültigkeitsbereich der Variablen. 

Im Beispiel in Abbildung 1.3 hatten wir angenommen, daß die drei Bezeichner Varia- 

2 Im Gegensatz zu unserer Terminologie werden die Begriffe Syntaxbaum und Strukturbaum in 

10 

[WM96] synonym verwendet. 

60


blen vom Typ REAL darstellen. Bei der Typüberprüfung des Programms wird in der 

semantischen Analyse festgestellt, daß die ganze Zahl 60 mit dem Inhalt einer REAL- 

Variablen multipliziert werden soll. Daher wird in den Syntaxbaum die Information 

eingefügt, daß vor der Multiplikation eine Typumwandlung der Zahl vorgenommen 

werden muß. 

1.5.2 Synthese 

In den Synthesephasen wird das zum Quellprogramm gehörende Zielprogramm erzeugt. 

Dabei werden die Informationen, die in den Analysephasen über den Programmtext 

gesammelt wurden, verwendet. 

Zwischencode-Erzeugung: Vor der Erzeugung des eigentlichen Zielprogramms wird 

oft eine Zwischendarstellung des Programms generiert, die einerseits bereits maschinennah, 

andererseits noch an keiner konkreten Zielmaschine orientiert ist. Diese Zwischensprache 

wird Zwischencode genannt. 

In Abbildung 1.3 wird als Zwischencode ein Drei-Adreß-Code erzeugt. Jeder Befehl 

dieses Codes darf maximal drei Adressen verwenden. Zwei Adressen geben an, wo 

sich die Operanden des Befehls befinden. Die dritte Adresse bezeichnet den Speicherplatz, 

an dem das Ergebnis des Befehls abgelegt werden soll. Die Speicherzellen an 

den Adressen id1, id2 und id3 enthalten die Werte der zugehörigen Variablen. Die 

Adressen temp1, temp2 und temp3 bezeichnen temporäre Speicherplätze für Zwischenergebnisse. 

Code-Optimierung: Die Verwendung eines maschinenunabhängigen Zwischencodes 

bietet den Vorteil, daß auf dem erzeugten Zwischencode eine ebenfalls maschinenunabhängige 

Code-Optimierung vorgenommen werden kann. Bei dieser Optimierung 

wird der Zwischencode auf Redundanzen hin untersucht und in bezug auf Laufzeit 

und Speicherplatzverbrauch verbessert. 

Im Beispiel wird in der Code-Optimierung erkannt, daß statt der Umwandlung einer 

ganzen Zahl in eine REAL-Zahl gleich die entsprechende Fließkommakonstante im 

Code verwendet werden kann. Hierdurch entfallen ein temporärer Speicherplatz und 

eine Konvertierungs-Operation. Außerdem kann das Ergebnis des Additionsbefehls 

direkt in id1 gespeichert werden, so daß die letzte Zuweisung entfällt. 

Code-Generierung: In dieser letzten Compilerphase wird das Zielprogramm für 

die Zielmaschine erzeugt. Dabei wird jeder Befehl des optimierten Zwischencodes in 

eine kurze Sequenz von Maschinenbefehlen übersetzt. Nach Möglichkeit werden die 

Speicherplätze des Zwischencodes durch Register der konkreten Maschine ersetzt, um 

zeitaufwendige Zugriffe auf den Hauptspeicher zu vermeiden. 

11

1 Einführung 

Eventuell schließt sich an die Phase der Code-Generierung noch eine maschinenabhängige 

Code-Optimierung an, die Ineffizienzen im erzeugten Maschinencode beseitigt 

(z.B. überflüssige Kopierbefehle entfernt oder einzelne Maschinenbefehle durch 

effizientere Befehle mit derselben Wirkung ersetzt). 

1.5.3 Front-End, Back-End 

Bei der Einteilung des Compilers in Phasen werden häufig die Begriffe Front-End 

und Back-End verwendet. Das Front-End eines Compilers umfaßt alle zielsprachenunabhängigen 

Compilerphasen, das Back-End entsprechend alle quellsprachenunabhängigen 

Phasen des Compilers. 

Für die Portierung eines Compilers auf eine andere Zielsprache kann i. allg. das Front- 

End unverändert weiterverwendet werden, so daß nur das entsprechende Back-End 

neu implementiert werden muß. Im umgekehrten Fall kann die Verbindung mehrerer 

Front-Ends mit einem gemeinsamen Back-End sinnvoll sein, um innerhalb eines Programms 

Teilprogramme in einer jeweils für das Teilproblem optimalen Programmiersprache 

zu schreiben und aus diesen Teilprogrammen ein gemeinsames Zielprogramm 

zu erzeugen. 

1.5.4 Läufe 

Es ist üblich, mehrere Übersetzungsphasen in einem einzelnen Lauf (pass) zu implementieren. 

Ein Lauf steht dabei für einen Durchlauf durch eine Darstellung des 

Programms. Dabei kann es sich sowohl um den Quelltext als auch um eine interne 

Darstellung des Programms wie z.B. den Syntaxbaum handeln. Dabei bietet es 

sich an, Phasen, deren Arbeitsschritte eng miteinander verzahnt sind, in einem Lauf 

zusammenzufassen. Eine Möglichkeit wäre zum Beispiel die Integration von lexikalischer 

und syntaktischer Analyse in einem Lauf sowie der semantischen Analyse und 

der Codegenerierung in einem zweiten Lauf. 

Einen Extremfall stellt der Ein-Pass-Compiler dar, der die Analyse des Quellprogramms 

und die Synthese des Zielprogramms während eines einzigen Durchlaufs 

durch den Programmtext durchführt. In diesem Fall muß gewährleistet sein, daß 

jeder Bezeichner vor seiner Verwendung deklariert wurde, da nachträgliche Änderungen 

am Zielprogramm nicht mehr möglich sind. Aus diesem Grund ist in vielen 

Compilern für die Sprache Pascal [JW91] die Vordeklaration von Bezeichnern mit 

der forward-Anweisung vorgesehen. 

Andere Programmiersprachen wie z.B. Algol-68 [OT97] erlauben die Verwendung von 

Bezeichnern vor ihrer Deklaration, so daß für diese Sprachen die Implementierung 

mittels eines Ein-Pass-Compilers nicht möglich ist. 

Bei der Implementierung einer Sprache mittels einer virtuellen Maschine gilt: Der 

12


vom Compiler erzeugte Code ähnelt dem idealisierten Zwischencode, der durch die 

virtuelle Maschine interpretiert wird, also auf Instruktionen der realen Hardware 

zum Zeit der Ausführung abgebildet wird. Somit kann die virtuelle Maschine auch 

als Middle-End bezeichnet werden. Das bedeutet in der Regel aber nicht, dass bei 

dieser Variante die Phase der Zwischencode-Erzeugung entfällt. Vielmehr existiert im 

Allgemeinen eine weitere Zwischendarstellung des Programms zwischen semantischer 

Analyse und dem Code für die virtuelle Maschine, auf deren Grundlage Optimierungen 

unabhängig von der VM durchgeführt werden können. 

13

2 Lexikalische Analyse 

Die lexikalische Analyse arbeitet als erste Phase des Compilers direkt mit dem zu 

übersetzenden Programmtext (siehe Abbildung 2.1). 

Der Programmteil zur Durchführung der lexikalischen Analyse wird Scanner genannt. 

Der Scanner erfüllt die folgenden Aufgaben: 

• Das Quellprogramm wird zeichenweise gelesen und dabei in Symbole zerlegt. 

Bei dieser Zerlegung werden Leerzeichen, Kommentare, Zeilenenden etc. entfernt, 

so daß sie in den weiteren Compilerphasen nicht mehr beachtet werden 

müssen. 

• Die Bezeichner des Programms werden in der Reihenfolge ihres Auftretens im 

Quelltext mit erläuternden Informationen in die Symboltabelle eingefügt. 

• Für die eventuelle Ausgabe von Fehlermeldungen werden Informationen gesammelt 

(z.B. Zeilennummern). 

Ein wichtiger Gesichtspunkt bei der Realisierung eines Scanners ist Effizienz, da die 

nachfolgenden Phasen des Compilers direkt vom Scanner abhängig sind und deren 

Laufzeit daher durch einen langsamen Scanner negativ beeinflußt wird. Meist wird 

der Scanner als Unterprogramm des Parsers realisiert (eventuell als Coroutine). Der 

Scanner liefert jeweils nach Aufforderung durch den Parser ein Symbol. 

2.1 Terminologie 

In diesem Abschnitt führen wir die Begriffe Symbol, Muster und Lexem ein. 

Quellprogramm 

Symbol 

Scanner Parser 

nächstes Symbol 

anfordern 

Symboltabelle 

Abbildung 2.1: Interaktion zwischen Scanner und Parser.

2.2 Reguläre Sprachen und endliche Automaten 

Symbole sind die vom Scanner an den Parser zu liefernden Grundeinheiten der Programmiersprache. 

Mengen von gleichartigen Symbolen nennen wir Symbolklassen. 

Typische Symbolklassen sind die Menge der Integer-Konstanten und die Menge der 

Zeichenketten. 

Muster beschreiben die möglichen Auftreten eines Symbols im Quellprogramm. Die 

Zeichenfolgen im Programmtext, die Symbolen entsprechen, nennen wir Lexeme. 

Beispiele für Symbole und die zugehörigen Muster und Lexeme sind in Tabelle 2.1 

angeführt. 

Symbol Musterbeschreibung mögliche Lexeme 

if if if 

id Buchstabe, gefolgt von pi, D2 

Buchstaben oder Ziffern 

Tabelle 2.1: Beispiele für Symbole, Muster und Lexeme. 


Grundlage für die lexikalische Analyse ist die Theorie der regulären Sprachen. 

Wir wiederholen zunächst einige wichtige Grundbegriffe der formalen Sprachen. 

Ein Alphabet Σ ist eine endliche Menge von Zeichen; z.B. {0, 1}, 

{0,..., 9,A,...,Z} oder der ASCII-Zeichensatz. 

Ein Wort über einem Alphabet Σ ist eine endliche Folge von Zeichen aus dem Alphabet; 

z.B. 01001, A195, goltz@ips.cs.tu-bs.de. Das leere Wort bezeichnen wir mit 

ε. Die Menge aller Wörter über einem Alphabet Σ bezeichnen wir mit Σ ∗ . 

Eine Sprache über einem Alphabet ist eine Menge von Wörtern über dem Alphabet, 

z.B. ∅, {ε}, {A,B,C,AB,AC,ABC} sowie die Menge aller syntaktisch wohlgeformten 

Modula 2-Programme. 

Seien v und w Wörter über dem Alphabet Σ. Die Konkatenation von v und w, 

geschrieben vw, ist dasjenige Wort, das durch das Anhängen von w an v ensteht. Für 

v = compiler und w = bau ergibt sich als Konkatenation vw das Wort compilerbau. 

Es gilt εw = wε = w für beliebige Wörter w. 

Die Exponentiation von Wörtern ist wie folgt definiert: 

• w 0 = ε 

• w i = w i−1 w für i > 0. Es gilt w 1 = w. 

Operationen auf Sprachen: Seien L,M Sprachen. Dann sind die folgenden Operationen 

definiert: 

15


Vereinigung: L ∪ M := {w | w ∈ L ∨ w ∈ M} 

Konkatenation: LM := {vw | v ∈ L ∧ w ∈ M} 

Exponentiation: L 0 := {ε}, 

L i := L i−1 L für i > 0 

Kleene-Abschluß: L ∗ := � ∞ i=0 L i 

Positiver Abschluß: L + := � ∞ i=1 L i 

Beispiel 1 

Seien L = {A,B,...,Z,a,b,...,z} und D = {0, 1,..., 9} Sprachen mit Wörtern der 

Länge 1. Dann ist 

L ∪ D die Sprache der Buchstaben und Ziffern, 

LD die Sprache, die lauter Wörter der Form Buchstabe Ziffer 

enthält, 

L 4 die Sprache aller Wörter mit genau vier Buchstaben über L, 

L ∗ die Sprache aller beliebig langen Wörter aus Buchstaben 

(inkl. ε), 

L((L ∪ D) ∗ ) die Sprache aller Wörter aus Buchstaben und Ziffern, 

die mit einem Buchstaben beginnen, 

D + die Sprache aller nicht-leeren Wörter aus Ziffern. 

2.2.1 Reguläre Sprachen 

Sei Σ Alphabet. 

Definition 1 

Die regulären Sprachen über Σ sind induktiv definiert durch 

• ∅ ist reguläre Sprache, 

• für alle a ∈ Σ ist {a} reguläre Sprache, 

• falls L1,L2 reguläre Sprachen, so sind auch L1 ∪ L2, L1L2 und L ∗ 1 reguläre 

Sprachen. 

Nichts sonst ist eine reguläre Sprache über Σ. 

Bemerkung: {ε} wird durch den ∗ -Operator aus ∅ gewonnen. Also ist {ε} regulär. 

2.2.2 Reguläre Ausdrücke 

Reguläre Ausdrücke sind spezielle Formeln, mit denen reguläre Sprachen definiert 

werden. 

Definition 2 

Die Menge der regulären Ausdrücke über Σ, reg(Σ), ist induktiv definiert durch 

16


• ∅ ∈ reg(Σ), 

• ε ∈ reg(Σ), 

• für jedes a ∈ Σ ist a ∈ reg(Σ), 

• falls r1,r2 ∈ reg(Σ), dann (r1|r2) ∈ reg(Σ), (r1r2) ∈ reg(Σ) und (r1) ∗ ∈ 

reg(Σ). 

Bemerkung: Die Zeichen (, ), |, ∗ in regulären Ausdrücken sind Metazeichen. Sie sind 

keine Elemente des Alphabets Σ, sondern dienen als Operatoren zur Bildung der 

regulären Ausdrücke. Die Metazeichen müssen von den Zeichen des Alphabets zu 

unterscheiden sein, damit die von dem regulären Ausdruck beschriebene Sprache 

eindeutig zu bestimmen ist. Sind die Metazeichen im Alphabet Σ enthalten, wird 

die hieraus resultierende Doppeldeutigkeit durch eine spezielle Kennzeichnung der 

Metazeichen vermieden (siehe Beispiel 2). 

Die Sprache, die von einem regulären Ausdruck definiert wird, wird in der folgenden 

Definition eingeführt. 

Definition 3 

Sei r regulärer Ausdruck. Die Sprache L(r) ist induktiv definiert durch 

• L(∅) = ∅ 

• L(ε) = {ε} 

• L(a) = {a} 

• L(( r1 | r2)) = L(r1) ∪ L(r2), 

L((r1 r2)) = L(r1)L(r2), 

L((r1) ∗ ) = (L(r1)) ∗ 

Bemerkung: Es gilt: r ∈ reg(Σ) ⇔ L(r) ist reguläre Sprache. 

Wir verdeutlichen die regulären Ausdrücke anhand von Beispielen. 

Beispiel 2 

• a | b beschreibt {a} ∪ {b} = {a,b} 

• (a b) ∗ beschreibt ({a}{b}) ∗ = {ab} ∗ = {ε,ab,abab,...} 

• (A|...|Z|a|...|z) beschreibt {A,...,Z,a,...,z} 

• Sei Σ = {(, )}. Die Zeichen des Alphabets sind in den Metazeichen regulärer 

Ausdrücke enthalten. Daher kennzeichen wir die Metazeichen durch Unterstreichung. 

Damit beschreibt ( ( ) ∗ ) die Sprache, deren Wörter mit beliebig vielen 

öffnenden Klammern beginnen und mit einer schließenden Klammer enden: 

{), (), ((), (((),...} 

17


Konventionen: Um bei der Angabe regulärer Ausdrücke Klammern zu sparen und 

Mehrdeutigkeiten zu vermeiden, ordnen wir den Operatoren dieser Ausdrücke Prioritäten 

zu. 

• • hat die höchste Priorität, so daß a|b ∗ und (a|b) ∗ unterschiedliche Sprachen 

beschreiben. Zudem ist der ∗-Operator linksassoziativ, d.h. a ∗∗ = (a ∗ ) ∗ . 

• Die Konkatenation besitzt die zweithöchste Priorität und ist ebenfalls linksassoziativ. 

• | hat die niedrigste Priorität ( (a|b) ∗ c vs. a|b ∗ c ) und ist ebenfalls linksassoziativ. 

Bemerkung: Unterschiedliche reguläre Ausdrücke können dieselbe Sprache beschreiben. 

So ist L((a|b)(a|b)) = {aa,ab,ba,bb} = L(aa|ab|ba|bb). 

Algebraische Eigenschaften: Für die Operatoren | und Konkatenation gelten die 

folgenden algebraischen Eigenschaften, wobei wir reguläre Ausdrücke genau dann 

gleichsetzen, wenn sie dieselbe Sprache beschreiben (r = s bedeutet L(r) = L(s)): 

• r|s = s|r (Kommutativität von |) 

• r|(s|t) = (r|s)|t (Assoziativität von |) 

• r(st) = (rs)t (Assoziativität der Konkatenation) 

2.2.3 Endliche Automaten 

Nach der Einführung der regulären Sprachen und der regulären Ausdrücke in den 

vorigen Abschnitten geben wir nun einen Mechanismus zur Erkennung von Wörtern 

regulärer Sprachen an. Hierzu verwenden wir die endlichen Automaten. 

Definition 4 

Ein nichtdeterministischer endlicher Automat (NEA) ist ein Tupel M = (Σ,Q, ∆,q0,F), 

wobei 

• Σ endliches Alphabet (das Eingabealphabet), 

• Q endliche Menge (von Zuständen), 

• q0 ∈ Q (der Anfangszustand), 

• F ⊆ Q (die Menge der Endzustände) und 

• ∆ ⊆ Q × (Σ ∪ {ε}) × Q (die Übergangsrelation) ist. 

Definition 5 

Sei M = (Σ,Q, ∆,q0,F) ein NEA. 

Ein Paar (q,w),q ∈ Q,w ∈ Σ ∗ heißt Konfiguration von M, (q0,w) heißt Anfangskonfiguration, 

(qf,ε) mit qf ∈ F Endkonfiguration. 

Die Schritt-Relation ist eine binäre Relation ⊢M⊆ (Q × Σ ∗ ) × (Q × Σ ∗ ), definiert 

durch 

18


(q,aw) ⊢M (q ′ ,w) :⇔ (q,a,q ′ ) ∈ ∆ für q,q ′ ∈ Q und a ∈ Σ oder a = ε. 

⊢ ∗ M sei die reflexive transitive Hülle von ⊢M. 

Die von M akzeptierte Sprache ist L(M) = {w ∈ Σ ∗ | (q0,w) ⊢ ∗ M (qf,ε), 

qf ∈ F }. 

Ein endlicher Automat soll ein Eingabewort daraufhin überprüfen, ob es zu einer 

bestimmten Sprache gehört. Dabei wird die Eingabe von links nach rechts zeichenweise 

gelesen. Zu Beginn befindet sich der Automat im Anfangszustand q0 und der 

Eingabezeiger zeigt auf das erste Zeichen des Eingabewortes. Nach dem Lesen eines 

Zeichens wird das entsprechende Zeichen aus der Eingabe entfernt und der Automat 

geht in Abhängigkeit vom gelesenen Zeichen mittels der Übergangsrelation in einen 

neuen Zustand über. Weiterhin ist der Übergang in einen anderen Zustand ohne das 

Lesen eines Eingabezeichens möglich (ε-Übergang). Ein Übergang eines Automaten 

in einen anderen Zustand wird Schritt genannt. Ist die Eingabe vollständig gelesen 

und der Automat befindet sich in einem Endzustand, wird das gelesene Wort 

akzeptiert. Befindet sich der Automat nach dem vollständigen Lesen der Eingabe 

nicht in einem Endzustand oder ist in einem Zustand kein Übergang für das nächste 

Eingabezeichen möglich, wird das Eingabewort verworfen. 

Das Verhalten eines NEA wird also in jedem Schritt durch den aktuellen Zustand 

des Automaten und die restliche Eingabe bestimmt. Diese beiden Faktoren bilden 

zusammen die aktuelle Konfiguration des endlichen Automaten. Die Übergänge 

zwischen Konfigurationen werden durch die Schritt-Relation beschrieben. 

Der Automat erkennt die Worte, für die er durch eine Folge von Schritten aus der Anfangskonfiguration 

eine Endkonfiguration erreichen kann. Die Menge der von einem 

NEA erkannten Worte bildet die von ihm akzeptierte Sprache. 

Graphische Darstellung: Zur Verbesserung der Übersichtlichkeit werden NEAs 

durch Übergangsgraphen dargestellt. Die Knoten des Graphen repräsentieren die 

Zustände des Automaten. Die Kanten stellen die Zustandsübergänge des Automaten 

dar und sind mit dem Zeichen beschriftet, das während des Übergangs gelesen wurde 

(bzw. mit ε, falls kein Zeichen gelesen wurde). 

Beispiel 3 

Der Übergangsgraph in Abbildung 2.2 stellt einen NEA dar, der die Sprache L((a|b) ∗ abb) = 

{abb,aabb,babb,aaabb,ababb,...} akzeptiert. 

Ein NEA akzeptiert ein Eingabewort w genau dann, wenn es im Übergangsgraphen 

einen Pfad vom Startzustand in einen Endzustand gibt, so daß die gelesenen Eingabesymbole 

die Kanten des Pfades beschriften. 

Die Übergangsrelation ∆ eines NEA kann in Form einer Tabelle dargestellt werden. 

Die Tabelle 2.2 enthält die Übergangsrelation des in Abbildung 2.2 dargestellten 

Automaten. 

19


a 

a b b 

0 1 2 3 

b 

Abbildung 2.2: Beispiel eines Übergangsgraphen. 

Zustand / Eingabe a b ε 

0 {0, 1} {0} - 

1 - {2} - 

2 - {3} - 

3 - - - 

Tabelle 2.2: Übergangsrelation ∆ in Tabellenform. 

Satz 1 

Zu jedem regulären Ausdruck r gibt es einen nichtdeterministischen endlichen Automaten, 

der die von r beschriebene reguläre Sprache akzeptiert. 

Beweis 

Wir führen den Beweis konstruktiv durch, indem wir für jeden regulären Ausdruck 

eine Überführung in entsprechende “Automaten” angeben, wobei Kanten zunächst 

mit regulären Ausdrücken beschriftet sein dürfen. Handelt es sich bei dem Ausdruck r 

um ∅, der die leere Sprache beschreibt, besteht der Automat aus nur einem Zustand, 

der zugleich Endzustand ist, und enthält keine Übergänge. Andernfalls beginnen wir 

mit einem Graphen für den regulären Ausdruck r, wie er in in Abbildung 2.3 oben 

angegeben ist. Die Überführungsschritte für die einzelnen Operatoren sind in Abbildung 

2.3 aufgeführt. r,r1,r2 sind reguläre Ausdrücke. (A) beschreibt die Behandlung 

der Alternative, (K) der Konkatenation, (S) des Stern-Operators und (KL) die Behandlung 

von Klammern. � 

Beispiel 4 

In Abbildung 2.4 wird schrittweise der Automat für den regulären Ausdruck a(a|0) ∗ 

konstruiert. Neben den einzelnen Konstruktionsschritten ist die Regel aus Abbildung 

2.3 angegeben, die in diesem Schritt verwendet wurde. 

20

q♥ r 

✓✏ 

p♥ 

✒✑ 

r1|r2 

q♥ ♥p � q♥ ♥p 

r1r2 

q♥ p♥ � q♥ q1 ♥ ♥p 


♥ r 

q ♥p ♥q q1 ♥ q2 ♥ p♥ 

∗ ε ε 

� 

♥ (r) 

q ♥p q♥ r 

� 

p♥ 

r1 

r2 

r1 

ε 

r 

ε 

r2 

(A) 

(K) 

(S) 

(KL) 

Abbildung 2.3: Konstruktion eines NEA zu einem regulärem Ausdruck. 

✓✏ 

♠a(a|0) 0 1♠ 

✒✑ 

∗ 

✓✏ 

♠ ♠ (a|0) 

0 2 1♠ 

✒✑ 

∗ 

a 

0♠ a ♠ε 2 

(a|0) 

3♠ ε 

4♠ ε 

✓✏ 

1♠ 

✒✑ 

0♠ a ♠ε 2 

a 

3♠ 0 

ε 

4♠ ε 

✓✏ 

1♠ 

✒✑ 

ε 

ε 

(K) 

(S) 

(KL),(A) 

Abbildung 2.4: Beispiel einer NEA-Konstruktion. 

21


Da es sich bei dem mit dem Verfahren erzeugten Automaten um einen nichtdeterministischen 

endlichen Automaten handelt, ist eine direkte Umsetzung des Automaten 

in ein Programm aufgrund des Nichtdeterminismus nicht ohne weiteres möglich. 

Aus der Theorie der formalen Sprachen ist bekannt, daß es zu jedem NEA einen 

deterministischen endlichen Automaten (DEA) gibt, der dieselbe Sprache erkennt. 

Definition 6 

Sei M = (Q, Σ, ∆,q0,F) ein NEA. M heißt deterministischer endlicher Automat 

(DEA), wenn ∆ eine Funktion σ : Q × Σ → Q ist. 

In einem DEA treten keine ε-Übergänge auf. Weiterhin gibt es für jeden Zustand 

unter jeder Eingabe höchstens einen Folgezustand. 

Satz 2 

Wird eine Sprache L von einem NEA akzeptiert, so gibt es einen DEA, der L akzeptiert. 

Beweis 

Der Beweis wird konstruktiv geführt, indem wir ein Verfahren angeben, das zu einem 

NEA einen DEA generiert, der dieselbe Sprache erkennt. Dieses Verfahren wird 

Potenzmengenkonstruktion genannt. 

Die Potenzmengenkonstruktion verwendet die beiden folgenden Definitionen: 

Definition 7 

Sei M = (Q, Σ, ∆,q0,F) ein NEA und sei q ∈ Q. Die Menge der ε-Folgezustände 

von q ist 

ε − FZ(q) = {p | (q,ε) ⊢ ∗ M (p,ε)}, 

also die Menge aller Zustände p, inklusive q, für die es einen ε-Weg im Übergangsgraphen 

zu M von q nach p gibt. Wir erweitern ε − FZ auf Mengen von Zuständen 

S ⊆ Q: 

ε − FZ(S) = � 

ε − FZ(q). 

Definition 8 

Sei M = (Q, Σ, ∆,q0,F) ein NEA. 

Der zu M gehörende DEA M ′ = (Q ′ , Σ,δ,q ′ 0,F ′ ) ist definiert durch: 

Q ′ = P(Q), die Potenzmenge von Q, 

q ′ 0 = ε − FZ(q0), 

F ′ = {S ∈ Q ′ | S ∩ F �= ∅} und 

δ(S,a) = ε − FZ({p | (q,a,p) ∈ ∆ für q ∈ S}) für a ∈ Σ,S ∈ Q ′ . 

22 

q∈S


Der folgende Algorithmus konstruiert zu einem NEA M den zu M gehörenden DEA 

M ′ , wobei nicht erreichbare Zustände weggelassen werden. 

Algorithmus NEA nach DEA 

Eingabe: NEA M = (Q, Σ, ∆,q0,F) 

Ausgabe: DEA M ′ = (Q ′ , Σ,δ,q ′ 0,F ′ ) 

1 q ′ 0 := ε − FZ(q0); Q ′ := {q ′ 0};\\ 

2 marked(q ′ 0) := false; δ := ∅;\\ 

3 while e x i s t i e r t S ǫ Q ′ and marked(S) = false do 

4 marked(S) := true; 

5 foreach a ǫ Σ do 

6 T := ε − FZ({p ǫ Q | (q,a,p) ǫ ∆ und q ǫ S}) 

7 if T /∈ Q ′ then 

8 Q ′ := Q ′ ∪ {T }; (∗ neuer Zustand ∗) 

9 marked(T) := false 

10 fi ;\\ 

11 δ := δ ∪ {(S,a) ↦→ T } (∗ neuer ”Ubergang ∗) 

12 od 

13 od 

Die Zustände von M ′ sind Mengen von Zuständen von M (daher der Name Potenzmengenkonstruktion). 

Zwei Zustände p und q von M fallen in dieselbe Zustandsmenge 

S (also in denselben Zustand von M ′ ), wenn es ein Wort w gibt, welches den NEA M 

sowohl nach p als auch nach q bringt. Nach Definition 8 erhält man den Folgezustand 

eines Zustands S in M ′ unter einem Zeichen a, indem man die Nachfolgezustände 

aller Zustände q ∈ S unter a zusammenfaßt und deren ε-Folgezustände hinzufügt. 

Wir verdeutlichen die Arbeitsweise der Potenzmengenkonstruktion, indem wir für den 

in Abbildung 2.4 erzeugten NEA einen DEA generieren, der ebenfalls die durch den 

regulären Ausdruck a(a|0) ∗ beschriebene Sprache erkennt. In Abbildung 2.5 [WM96] 

sind die einzelnen Schritte des Verfahrens dargestellt. Die Zustände des zu konstruierenden 

DEA sind mit 0 ′ , 1 ′ , 2 ′ und ⊘ benannt, wobei 0 ′ der Anfangszustand ist. ⊘ ist 

ein “Fehlerzustand”, der als Folgezustand eines Zustands q unter a verwendet wird, 

wenn es keinen Übergang im NEA unter a aus q heraus gibt. Sind für einen Zustand 

des DEA für alle möglichen Zeichen aus Σ die entsprechenden Nachfolgezustände des 

DEA berechnet, wird der Zustand markiert (in Abbildung 2.5 durch Unterstreichung 

dargestellt) und braucht nicht weiter behandelt zu werden. Endzustände des DEA 

sind die Zustände, in deren Menge von Zuständen des NEA ein Endzustand auftritt 

(1 ′ und 2 ′ sind Endzustände, da sie den NEA-Endzustand 1 beinhalten). 

� 

23


24 

0 ′ = {0}; Q ′ = {0 ′ } 

ausgewählter Zustand neues Q 

✗✔ 

✎☞ 

✎☞✘✘✘✘ 

✖✕ 

✍✌ 

✍✌❍ 

❍❍❍ ✎☞ 

✍✌ 

✗✔ 

✎☞ 

✎☞✘✘✘✘ 

✖✕ ✍✌ 

✍✌❝ 

❝❝❝ 

✎☞ 

✗✔ 

✎☞ 

✖✕ ✍✌ 

✍✌ 

′ neuer (Teil-) DEA 

0 ′ 

0 ′ 

1 ′ 

1 ′ 2 ′ 

0 

a 

0 ⊘ 

a 

a 

0 

0 

⊘ 

a a 

′ {0 ′ , 1 ′ , ⊘} mit 

1 ′ = {1, 2, 3} 

1 ′ {0 ′ , 1 ′ , 2 ′ , ⊘} mit 

2 ′ = {1, 3, 4} 

2 ′ {0 ′ , 1 ′ , 2 ′ , ⊘} 

⊘ {0 ′ , 1 ′ , 2 ′ , ⊘} 

✗✔ ✎☞ 

✎☞✘✘✘✘ ✖✕ ✍✌ 

✍✌ 0 

❅ 

❅❅❅ 

✎☞ 

✗✔ ✎☞ 

✖✕ ✍✌ 

✍✌ 

✗✔ ✎☞ 

✎☞✘✘✘✘ ✖✕ ✍✌ 

✍✌ 

❅ 

❅❅❅ 

✎☞ 

✍✌ 

✗✔ ✎☞ 

✖✕ ✍✌ 

′ 

0 ′ 

1 ′ 

1 ′ 

2 ′ 

2 ′ 

a 

0 

0 

0 

⊘ a 

a 

0 

0 

⊘ 

a 

0 

Abbildung 2.5: Beispiel zur Potenzmengenkonstruktion. 

a 

0


Da der durch das Verfahren erzeugte DEA i. allg. nicht der “kleinstmögliche” Automat 

ist, wird im Anschluß an die Potenzmengenkonstruktion ein weiteres Verfahren, 

genannt Minimalisierung, durchgeführt, das zu dem erzeugten DEA einen weiteren 

DEA konstruiert, der dieselbe Sprache akzeptiert und über eine minimale Zustandsmenge 

verfügt. In dem durch die Potenzmengenkonstruktion erzeugten DEA kann 

es noch Zustände mit gleichem “Akzeptanzverhalten” geben. Zwei Zustände p und q 

besitzen das gleiche Akzeptanzverhalten, wenn der Automat aus p und q unter allen 

Eingabewörtern entweder immer oder nie in einen Endzustand geht. Die Minimalisierung 

beruht auf dem Zusammenfassen dieser Zustände zu einem gemeinsamen 

Zustand. 

Der folgende Algorithmus beschreibt das Verfahren der Minimalisierung. 

Algorithmus Minimalisierung. 

Eingabe: DEA M = (Q, Σ,δ,q0,F). 

Ausgabe: DEA Mmin = (Qmin, Σ,δmin,q0,min,Fmin) mit Qmin minimal. 

Methode: Die Zustandsmenge von M wird in eine Partition aufgeteilt, die schrittweise 

verfeinert wird. Für Zustände in verschiedenen Klassen einer Partition 

ist schon bekannt, daß sie verschiedenes Akzeptanzverhalten zeigen, d.h. daß es 

mindestens ein Wort w gibt, unter welchem aus einem der Zustände ein Endzustand 

erreicht wird und unter dem anderen nicht. Deshalb beginnt man mit der 

Partition Π = {F,Q − F }. In jedem Iterationsschritt des Verfahrens wird eine 

Klasse K aus der Partition entfernt und durch eine Menge von Verfeinerungen 

Ki ersetzt. Dabei gilt, daß für alle Zustände q in einer Verfeinerung Ki der 

Nachfolgezustand δ(q,a) unter einem Zeichen a in einer gemeinsamen Klasse 

K ′ i liegt. Wird eine solche Verfeinerung gefunden, wird die Variable changed auf 

true gesetzt. Der Algorithmus hält, wenn in einem Schritt die Partition nicht 

mehr verfeinert wurde. Da in jedem Iterationsschritt nur Klassen der aktuellen 

Partition evtl. in Vereinigungen neuer Klassen zerlegt werden, Q und damit 

auch P(Q) aber endlich sind, terminiert das Verfahren. Die Klassen der dann 

gefundenen Partition sind die Zustände von Mmin. Es gibt einen Übergang zwischen 

zwei neuen Zuständen P und R unter einem Zeichen a ∈ Σ, wenn es einen 

Übergang δ(p,a) = r mit p ∈ P und r ∈ R in M gab. 

1 Π = {F,Q − F }; 

2 do changed := false ; 

3 Π ′ := Π; 

4 foreach K ∈ Π do 

5 Π ′ := (Π ′ − {K}) ∪ {{Ki}1≤i≤n} , und die Ki sind maximal mit 

6 K = � 

1≤i≤n Ki , und ∀a ∈ Σ : ∃K ′ i ∈ Π : ∀q ∈ Ki : δ(q,a) ∈ K ′ i 

7 if n > 1 then changed := true fi (∗ K wurde 

aufgespalten ∗) 

25


✎ ☞ 

✍{0 

✌ 

′ } 

a 

✗ 

✎ ☞ 

✔a 

✖ 

✍{1 

✌ 

✕ 

′ , 2 ′ } 

Abbildung 2.6: DEA mit minimaler Zustandsmenge. 

Partition Klasse Aufspaltung 

{{0 ′ , ⊘}, {1 ′ , 2 ′ }} 

{0 ′ , ⊘} {0 ′ }, {⊘} 

{1 ′ , 2 ′ } nein 

{{0 ′ }, {⊘}, {1 ′ , 2 ′ }} keine weitere Aufspaltung 

{1 ′ , 2 ′ } bilden zusammen einen neuen Zustand 

{⊘} ist ein toter Zustand, da er nicht Endzustand ist und alle 

Übergänge aus ihm hinaus wieder in ihn hineingehen. 

8 od; 

9 Π := Π ′ 

Abbildung 2.7: Beispiel zur Minimalisierung. 

10 until not changed ; 

11 Qmin = Π−(Tot ∪ Unerreichbar ) ; 

q0,min 

die Klasse in Π, in der q0 ist. 

die Klassen, die ein Element aus F enthalten. 

Fmin 

δmin(K,a) = K ′ wenn δ(q,a) = p mit q ∈ K und p ∈ K ′ 

für ein und damit für alle a ∈ K. 

K ∈ Tot wenn K kein Endzustand ist und nur Übergänge 

in sich selbst enthält. 

K ∈ Unerreichbar wenn es keinen Weg vom Anfangszustand nach K gibt. 

Die Anwendung des Verfahrens der Minimalisierung auf den in Abbildung 2.5 konstruierten 

DEA liefert den in Abbildung 2.6 angegebenen DEA mit minimaler Zustandsmenge. 

In Abbildung 2.7 sind die dabei aufgetretenen Iterationsschritte angegeben. 

Mit Hilfe dieser drei Verfahren ist die Implementierung eines Scanners möglich: 

26 

1. Zuerst wird die zu erkennende Sprache, also die Menge der möglichen Lexeme 

für Symbole, durch reguläre Ausdrücke beschrieben. 

2. Im nächsten Schritt wird gemäß Satz 1 ein NEA konstruiert, der die von den 

regulären Ausdrücken beschriebene Sprache akzeptiert. 

0


3. Anschließend wird mit dem Verfahren der Potenzmengenkonstruktion ein DEA 

erzeugt, der dieselbe Sprache wie der NEA erkennt. 

4. Mit Hilfe des Verfahrens der Minimalisierung wird ein weiterer DEA konstruiert, 

der dieselbe Sprache wie der erste DEA erkennt, aber über eine minimale 

Zustandsmenge verfügt. 

5. Dieser minimale DEA kann nun als Grundlage für die Implementierung des 

Scanners verwendet werden. 

2.2.4 Reguläre Definitionen 

Der Übersichtlichkeit halber ist es wünschenswert, regulären Ausdrücken Namen geben 

zu können, damit diese Namen in anderen regulären Ausdrücken verwendet 

werden können. Diese Namen können wie Zeichen aus dem Alphabet in regulären 

Ausdrücken auftreten. 

Definition 9 

Sei Σ Alphabet. Dann ist eine reguläre Definition eine Folge 

d1 → r1 

d2 → r2 

... 

dn → rn, 

wobei di jeweils ein eindeutiger Name, ri ∈ reg(Σ ∪ {d1,...,di−1}) ist. 

Die Einschränkung ri ∈ reg(Σ ∪ {d1,...,di−1}) gewährleistet, daß kein Name eines 

regulären Ausdrucks in einem anderen Ausdruck verwendet wird, bevor der Name 

deklariert wurde. Insbesondere sind hierdurch keine rekursiven Definitionen möglich. 

Beispiel 5 

letter → A | B | ... | Z | a | b | ... | z 

digit → 0 | 1 | ... | 9 

id → letter ( letter | digit ) ∗ 

Diese reguläre Definition beschreibt (etwas vereinfacht) die Bezeichner, wie sie in 

Programmiersprachen auftreten. Bezeichner beginnen hier mit einem Buchstaben, 

dem eine beliebig lange Sequenz von Buchstaben und Zeichen folgen kann. 

Zur Verbesserung der Lesbarkeit werden folgende Abkürzungen vereinbart: 

Ein- oder mehrmaliges Auftreten: Sei r regulärer Ausdruck. Dann stehe r + für rr ∗ , 

d.h. L(r + ) = L(r) + . Priorität und Assoziativität gelten wie für den ∗ -Operator. 

27


Null- oder einmaliges Auftreten: Sei r regulärer Ausdruck. Dann stehe r? für r |ε, 

d.h. L(r?) = L(r) ∪ {ε}. 

Beispiel 6 

Der reguläre Ausdruck a + beschreibt die Menge aller nicht-leeren Wörter, die nur 

aus a’s bestehen. 

a?b ∗ beschreibt die Menge aller Wörter, die entweder nur b’s oder genau ein a und 

dann nur b’s enthalten. 

Beispiel 7 

Betrachten wir die Regeln einer kontextfreien Grammatik für einen Ausschnitt einer 

Programmiersprache: 

stmt → if expr then stmt 

| if expr then stmt else stmt 

| ε 

expr → term relop term 

| term 

term → id | num 

In der durch diese Regeln beschriebenen Programmiersprache treten folgende Symbole 

auf: if, then, else, relop, id, num. Der Scanner muß diese Symbole im Eingabestrom 

erkennen und herausfiltern. Die Symbole werden in Form einer regulären 

Definition spezifiziert: 

if → i f 

then → t h e n 

else → e l s e 

relop → = | < | | >= 

id → letter (letter | digit) ∗ 

num → digit + (. digit + )? (E (+ | -)? digit + )? 

Dabei seien letter und digit wie in Beispiel 5 definiert. num ist entweder einfache 

Integer-Zahl oder eine Fließkommazahl, wobei Nachkommastellen und ein positiver 

bzw. negativer Exponent angegeben werden können. 

Schlüsselwörter sollen hier nicht als Bezeichner verwendet werden dürfen. Daher wissen 

wir, daß bei Erkennen der Zeichenkette t h e n das Symbol then und nicht id 

an den Parser weitergereicht werden muß. 

Lexeme sind durch Leerräume getrennt, dabei sind Leerräume nicht-leere Folgen von 

Leerzeichen und Zeilenwechseln: 

delim → blank | newline 

sep → delim + 

blank und newline müssen dann in Abhängigkeit von der Implementierung interpretiert 

werden. 

28


Regulärer Ausdruck Symbol Attributwert 

sep – – 

i f if – 

t h e n then – 

e l s e else – 

id id Verweis auf Eintrag in der Symboltabelle 

num num Wert der Zahl 

< relop LT 

relop GT 

>= relop GE 

Tabelle 2.3: Reguläre Ausdrücke und die dazugehörigen Symbole und Attributwerte. 

Unser Ziel ist nun die Erstellung eines Scanners, der im Eingabestrom ein Lexem für 

das nächste Symbol identifiziert und als Ausgabe ein Paar aus Symbol und Attribut 

gemäß Tabelle 2.3 liefert. 

Bei der Erkennung der Lexeme tritt folgendes Problem auf: um die Lexeme eindeutig 

identifizieren zu können, muß der Scanner im Eingabestrom “vorausschauen” können. 

Zum Beispiel liefern 

then das Symbol then, 

thens das Symbol id, 

85 das Symbol num und 

85a einen lexikalischen Fehler ( steht für ein Leerzeichen). 

Das Vorausschauen im Eingabestrom wird lookahead genannt. Im allgemeinen genügt 

ein lookahead von 1 nicht. Daher sollte die Eingabe in einen Eingabepuffer kopiert 

werden, in dem über einen Zeiger auf das jeweils aktuelle Zeichen zugegriffen werden 

kann. Hierdurch wird ein Zurückschreiben von Zeichen aus dem lookahead durch 

Zurücksetzen des Zeigers ermöglicht. 

Ein weiteres Problem tritt bei der Erkennung der Schlüsselwörter der zu übersetzenden 

Sprache auf. Die Codierung der Erkennung von Schlüsselwörtern in Automaten 

resultiert in einer sehr großen Anzahl von Zuständen. Deshalb werden i. allg. 

Schlüsselwörter zunächst wie Bezeichner behandelt. Erst später wird zwischen Bezeichnern 

und Schlüsselwörtern differenziert, so daß die jeweils entsprechende Information 

an den Parser geliefert wird. 

Ein mögliches Verfahren besteht darin, die Schlüsselwörter vorab mit entsprechenden 

Informationen in die Symboltabelle einzutragen, um eine Unterscheidung von den 

Einträgen für Bezeichner zu ermöglichen. Eine weitere Möglichkeit besteht in der 

29


Kombination des Scanners mit einem Sieber (siehe Abschnitt 2.3). 

Beispiel 8 (Fortführung von Beispiel 7) 

Wir geben nun für die Symbole Übergangsgraphen an, die beschreiben, wie der Scanner 

arbeitet, wenn er vom Parser mit der Ermittlung des nächsten Symbols beauftragt 

wurde. Dabei gehen wir davon aus, daß der benötigte Teil der Eingabe in einem 

Puffer steht, der über einen Zeiger den Zugriff auf das aktuelle Zeichen erlaubt. Am 

Anfang steht der Zeiger auf dem Zeichen hinter dem zuletzt gelesenen Lexem. 

In Abbildung 2.8 sind die Übergangsgraphen für die Symbole relop, id, num und sep 

angegeben. Vom Startzustand ausgehend wird je nach lookahead die entsprechende 

Kante ausgewählt. Wird ein Endzustand erreicht, wird das entsprechende Symbol an 

den Parser zurückgeliefert. Bei der Verwendung einer Kante wird das entsprechende 

Zeichen durch Weitersetzen des Zeigers aus der Eingabe gelöscht. Eventuell muß 

das gelesene Zeichen vom Scanner wieder in die Eingabe zurückgeschrieben werden 

(bzw. durch Rücksetzen des Zeigers wieder sichtbar gemacht werden), damit es für 

das nächste Symbol verwendet werden kann. Dies wird durch die Markierung ∗ an 

den entsprechenden Endzuständen signalisiert. Das Lexem für das an den Parser 

gelieferte Symbol besteht dann aus den Zeichen, die bis zur Verwendung der other- 

Kante gelesen wurden. Auf diese Weise erkennt der Automat auch die Symbole < 

und >, obwohl die Zustände 1 und 6 keine Endzustände sind. 

Ist der Endzustand des Graphen für das Symbol id erreicht, wird vor der Rückgabe 

des Symbols durch die Funktion gettoken() überprüft, ob es sich bei der gelesenen 

Zeichenkette um ein Schlüsselwort handelt. Ist dies der Fall, wird das zugehörige 

Symbol an den Parser geliefert. Andernfalls wird das Symbol id weitergegeben und 

der Bezeichner mittels install id() in die Symboltabelle eingetragen. Das Attribut des 

Symbols id enthält dann einen Verweis auf den Eintrag des Bezeichners. 

2.3 Sieber 

Bei der Implementierung eines Scanners wird oft die Identifizierung der für den Parser 

relevanten Symbole sowie die Erkennung von Schlüsselwörtern vom eigentlichen 

Scannen, also der Zerlegung der Eingabe, getrennt. Das entsprechende Teilprogramm, 

das diese Aufgaben übernimmt, wird Sieber genannt. 

Die Aufgaben des Siebers lassen sich wie folgt charakterisieren: 

30 

• Erkennung von Schlüsselwörtern: Der Scanner erkennt während der Zerlegung 

der Eingabe Bezeichner. Der Sieber untersucht, ob es sich bei einem 

Bezeichner um ein Schlüsselwort der zu erkennenden Sprache handelt. Ist dies 

der Fall, wird das zugehörige Symbol an den Parser weitergegeben. Handelt 

es sich nicht um ein Schlüsselwort, wird der Bezeichner in die Symboltabelle 

eingetragen (sofern noch kein Eintrag für ihn existiert) und das Symbol id

elop: 

Start 

id: 

Start 

num: 

Start 

sep: 

Start 

< = 

0 1 2 

= 

5 

3 

4 

> = 

6 7 

Buchstabe other 

9 10 11 

Ziffer 

> 

other 

other 

8 

Buchstabe oder Ziffer 

Ziffer 

2.3 Sieber 

Ziffer . Ziffer E 

+ oder - 

Ziffer other 

12 13 14 15 16 17 18 19 

Begrenzer other 

20 21 22 

Begrenzer 

* 

* 

* 

return(relop,LE) 

return(relop,NE) 

return(relop,LT) 

return(relop,EQ) 

return(relop,GE) 

return(relop,GT) 

return(gettoken(),install_id()) 

E Ziffer 

* 

Ziffer 

Abbildung 2.8: Übergangsgraphen für die Symbole des Beispiels. 

* 

31


mit einem Verweis auf den Eintrag als Attribut an den Parser geliefert. Die 

Funktionsweise des Siebers entspricht der Funktion gettoken() in Abbildung 

2.8. 

• Identifizierung der für den Parser relevanten Symbole: Nicht alle Symbole, 

die vom Scanner generiert werden, werden vom Parser benötigt. So ist 

z.B. die Weitergabe des Symbols sep nicht notwendig, da Informationen über 

Leerräume im Quelltext für die späteren Compilerphasen irrelevant sind. Dies 

gilt auch für die Kommentare, die sich in einem Quelltext befinden. Aus diesem 

Grund wird die Weitergabe dieser Symbole vom Sieber unterbunden, so daß nur 

die für die weiteren Phasen relevanten Symbole an den Parser weitergegeben 

werden. 

Beispiel 9 

In Abbildung 2.9 sind die lexikalische Analyse und die semantische Analyse eines 

Programmausschnitts dargestellt. In der Phase (A) zerlegt die lexikalische Analyse 

den Zeichenstrom in Symbole. In Phase (B) wandelt der Sieber die Bezeichner, die 

Schlüsselwörter darstellen, in entsprechende Symbole um. Gleichzeitig werden die Bezeichner, 

die keine Schlüsselwörter darstellen, in die Symboltabelle eingetragen und 

in der Symbolfolge durch ihren Index in dieser Tabelle ersetzt. Anschließend wird in 

Phase (C) die syntaktische Analyse durchgeführt und ein Strukturbaum erzeugt (siehe 

Kapitel 3). 

2.4 Fehlerbehandlung 

Enthält ein Quelltext lexikalische Fehler, soll der Scanner in der Lage sein, diese Fehler 

angemessen zu behandeln. Hierzu gehört zum einen die Ausgabe einer möglichst 

genauen Fehlermeldung, die Informationen über Art und Position (Zeilen- und Spaltennummern) 

des Fehlers enthält. Zum anderen soll der Scanner in der Lage sein, 

pro Analyse des Quelltexts möglichst viele Fehler zu finden, um die Anzahl der Compilerläufe 

zu vermindern. Daher ist es notwendig, daß der Scanner ein Verfahren 

beinhaltet, daß nach dem Finden eines Fehlers die weitere Analyse des Quelltexts 

erlaubt. Dieses Fortfahren mit der Analyse nach Auftreten eines Fehlers wird “Wiederaufsetzen” 

(recovery) genannt. 

Beim Scannen tritt eine Fehlersituation ein, wenn kein Präfix der Eingabe einem 

Symbolmuster entspricht. So kann in Beispiel 7 die Eingabe 2a keinem Symbolmuster 

entsprechen, da Bezeichner nicht mit einer Ziffer beginnen dürfen und Zahlen keine 

Buchstaben (außer E bzw. e in der Exponentialschreibweise) beinhalten können. 

Für das “Wiederaufsetzen” existieren verschiedene Verfahren: 

32 

• Panic Recovery: Bei diesem Verfahren werden nach Auftreten eines Fehlers 

solange Zeichen aus der Eingabe entfernt, bis wieder ein gültiges Lexem ge-

Abbildung 2.9: Analyse eines Programmausschnitts. 

33 

(C) 

(B) 

(A) 

IDLIST 

DECLIST 

DECL 

IDLIST 

TYP 

PROGRAM 

STATLIST 

STAT 

ASSIGN 

var id(1) com id(2) col int sem id(1) bec int("2") sem id(2) bec id(1) mul id(1) add int("1") 

id("var") sep id("a") com id("b") col id("int") sem sep id("a") bec int("2") sem sep id("b") bec id("a") mul id("a") add int("1") sem sep 

v a r a , b : i n t ; NL a : = 2 ; NL b : = a * a + 1 ; NL 

E 

T 

F 

STATLIST 

T 

F 

E 

T 

ASSIGN 

F 

E 

T 

F 

2.4 Fehlerbehandlung


funden wird (z.B. ein Leerzeichen, ein Zeilenende oder ein Schlüsselwort). Da 

die Eingabe endlich ist und bei diesem Verfahren verkürzt wird, terminiert 

der Scanner immer. Nachteilig kann sich auswirken, daß eventuell größere Abschnitte 

aus der Eingabe entfernt werden. Falls diese Abschnitte selbst Fehler 

enthalten, werden sie bei der aktuellen Analyse nicht entdeckt. 

• Löschen oder Einfügen einzelner Zeichen: Einige Fehler treten in Quelltexten 

häufiger auf. Hierzu gehören z.B. fehlende Leerzeichen zwischen Lexemen. 

Daher kann es sinnvoll ein, bei Auftreten eines Fehlers ein solches Trennzeichen 

einzufügen und dann die Analyse fortzusetzen. Dabei besteht die Gefahr, 

daß bei wiederholtem Einsetzen vor dem aktuellen Eingabesymbol das 

Verfahren nicht mehr terminiert. Neben dem Einfügen ist das Löschen von 

Zeichen sinnvoll. Besteht die Fehlersituation im Auftreten eines nicht erlaubten 

Zeichens im Quelltext (z.B. ? in einem Modula 2-Programm), kann dieses 

Zeichen entfernt und dann die Analyse des Programms fortgeführt werden. 

• Ersetzen von Zeichen: Eine weitere Möglichkeit besteht in der Ersetzung von 

fehlerhaften Zeichen. Tritt z.B. während des Scannens einer Zahl ein Buchstabe 

auf, kann dieser Buchstabe durch eine beliebige Ziffer ersetzt werden, um die 

Behandlung der weiteren Eingabe zu ermöglichen. 

Weitere Methoden für das “Wiederaufsetzen” sind denkbar. 

34

3 Syntaktische Analyse 

Die Aufgabe der syntaktischen Analyse ist die Überprüfung der syntaktischen Struktur 

eines Programmtextes. Die Durchführung der syntaktischen Analyse wird von 

einem Parser genannten Programmteil übernommen (siehe Abbildung 3.1). 

Die syntaktische Analyse 

• überprüft, ob die vom Scanner (siehe Kapitel 2) gelieferte Symbolfolge von der 

Grammatik der Quellsprache erzeugt werden kann; 

• liefert aussagefähige Fehlermeldungen und versucht, den fehlerhaften Programmtext 

auf weitere Fehler hin zu untersuchen; 

• erzeugt eine Darstellung, die die syntaktische Struktur eines Programmtextes 

wiedergibt (Strukturbaum oder parse tree). 

Die theoretische Grundlage der Syntaxanalyse sind die kontextfreien Grammatiken. 

3.1 Kontextfreie Grammatiken 

Wie in Kapitel 2 beschrieben, kann die lexikalische Struktur eines Programmtextes 

mit endlichen Automaten analysiert werden. Für die Definition der syntaktischen 

Struktur eines Programmtextes ist die Mächtigkeit der regulären Grammatiken jedoch 

nicht ausreichend. In Programmtexten treten häufig Klammerstrukturen auf 

(z.B. Klammern in arithmetischen Ausdrücken, begin und end), die von den regulären 

Grammatiken nicht erkannt werden können. Sei |w|a die Anzahl der Vorkommen des 

Zeichens a im Wort w. Die Sprache der wohlgeformten Klammerstrukturen wird 

Dycksprache genannt und ist wie folgt definiert: 

Quellprogramm 

Scanner 

Symbol 

nächstes Symbol 

anfordern 

Symboltabelle 

Parser 

parse tree 

Rest des Front-Ends 

Zwischendarstellung 

Abbildung 3.1: Interaktion zwischen Scanner, Parser und restlichem Front-End. 

35


{w | w ∈ (a|b) ∗ , |w|a = |w|b, ∀u,v,w = uv : |u|a ≥ |u|b}. 

Das Zeichen a entspricht der öffnenden Klammer, b analog der schließenden Klammer. 

Endliche Automaten können nicht “zählen”, d.h. sie sind nicht in der Lage, zu 

überprüfen, ob bisher mindestens so viele a’s wie b’s gelesen wurden und ob in einem 

Endzustand die Anzahl der a’s und b’s übereinstimmt. Aus diesem Grund ist die 

Dycksprache nicht regulär. Ein weiteres Beispiel für eine nichtreguläre Sprache ist 

{a n b n | n ≥ 0} [Sch08]. Für die Syntaxanalyse wird also die Klasse der kontextfreien 

Grammatiken verwendet. 

Zu jeder regulären Sprache gibt es einen endlichen Automaten, der die Sprache erkennt. 

Analog kann man für jede kontextfreie Grammatik einen sogenannten Kellerautomaten 

konstruieren, der die von der Grammatik definierte Sprache akzeptiert. 

3.1.1 Kontextfreie Grammatiken 

Zunächst definieren wir die kontextfreien Grammatiken. 

Definition 10 

Eine kontextfreie Grammatik ist ein Quadrupel G = (VN,VT,P,S) mit 

• VN,VT endliche Mengen (VN Menge der Nichtterminalsymbole, VT Menge der 

Terminalsymbole), 

• P ⊆ VN × (VN ∪ VT) ∗ (Menge der Produktionen oder Regeln), 

• S ∈ VN (Startsymbol). 

Terminale stehen für die Symbole, die in den zu analysierenden Programmen wirklich 

auftreten, und entsprechen somit den vom Scanner in der lexikalischen Analyse 

erzeugten Symbolen. 

Notationen: Wir unterscheiden im folgenden die Nichtterminale und die Terminale 

in den Produktionen einer Grammatik durch folgende Konventionen: 

36 

• Terminale werden dargestellt durch 

1. a, b, c, ..., 

2. Operatorsymbole +, −, ..., 

3. Satzzeichen, Klammern etc., 

4. Ziffern 0, ..., 9 und 

5. fettgedruckte Zeichenketten, z.B. id, while. 

Nichtterminale werden dargestellt durch


1. A, B, C, ... (S – bzw. die linke Seite der ersten Produktion einer Grammatik 

– Startsymbol) und 

2. kursiv gesetzte Zeichenketten, z.B. expr, stmt, Anw, Anw Folge. 

• Weiterhin gelten folgende Vereinbarungen: 

– X, Y , Z, ... stehen für einzelne Grammatiksymbole (Nichtterminale oder 

Terminale), 

– u, v, w, ..., z stehen für Wörter über Terminalsymbolen und 

– α, β, γ, ... stehen für Wörter über Grammatiksymbolen. 

• Für (A,α) ∈ P schreiben wir A → α (α = ε : ε-Produktionen). Mehrere 

Produktionen A → α1,...,A → αn für ein Nichtterminal A schreiben wir als 

A → α1 | ... | αn (Alternativen für A). 

Beispiel 10 (Arithmetische Ausdrücke) 

Die in Programmiersprachen häufig auftretenden arithmetischen Ausdrücke lassen 

sich (vereinfacht) wie folgt mit Hilfe einer kontextfreien Grammatik definieren: 

expr → expr op expr 

expr → ( expr ) 

expr → − expr 

expr → id 

op → + 

op → − 

op → * 

op → / 

op → ↑ 

Dabei sind expr und op Nichtterminale, expr ist das Startsymbol der Grammatik und 

id, +, −, ∗, /, ↑, (, ) sind die Terminale. 

Mit den oben angegeben Schreibkonventionen läßt sich die Darstellung der Grammatik 

verkürzen zu 

E → E A E | ( E ) | - E | id 

A → + | - | * | / | ↑ 

Beispiel 11 (Anweisungen einer imperativen Sprache) 

Die folgende kontextfreie Grammatik [WM96] definiert die Anweisungen einer einfachen 

imperativen Programmiersprache, deren Syntax ähnlich zu der von Pascal ist: 

37


Anw → If Anw | 

While Anw | 

Repeat Anw | 

Proz Aufruf | 

Wertzuweisung 

If Anw → if Bed then An Folge else An Folge fi | 

if Bed then An Folge fi 

While Anw → while Bed do An Folge od 

Repeat Anw → repeat An Folge until Bed 

Proz Aufruf → Name ( Ausdr Folge ) 

Wertzuweisung → Name := Ausdr 

An Folge → Anw | 

An Folge ; Anw 

Ausdr Folge → Ausdr | 

Ausdr Folge , Ausdr 

Eine Anweisung ist entweder eine If-Anweisung, eine While- oder Repeat-Schleife, 

ein Prozeduraufruf oder eine Wertzuweisung. Wir nehmen an, daß die Nichtterminale 

Bed für Bedingungen, Ausdr für Ausdrücke sowie Name für Bezeichner vordefiniert 

sind. Das Nichtterminal An Folge beschreibt Anweisungsfolgen. Dieses Nichtterminal 

ist rekursiv definiert: Eine Anweisungsfolge ist entweder eine einzelne Anweisung 

oder eine (kürzere) Folge, an die eine Anweisung nach einem ; angehängt wird. Das 

Nichtterminal Ausdr Folge beschreibt analog Folgen von Ausdrücken, in denen die 

einzelnen Ausdrücke durch , getrennt sind. 

Beispiel 12 (Grammatik mit ε-Produktionen) 

Die folgende Grammatik definiert begin-end-Blöcke in Pascal: 

Block → begin opt An Folge end 

opt An Folge → An Folge | ε 

An Folge → Anw | An Folge ; Anw 

Ein Block ist eine mit begin und end geklammerte Anweisungsfolge. Blöcke können 

in Pascal auch leer sein, so daß das Nichtterminal opt An Folge (für “optionale Anweisungsfolge”) 

auch zum leeren Wort ε abgeleitet werden kann. 

3.1.2 Ableitungen 

Wir betrachten die Produktionen kontextfreier Grammatiken als Ersetzungsregeln, 

die aus Wörtern über VN ∪ VT neue Wörter über VN ∪ VT “produzieren”, indem 

Nichtterminale durch rechte Regelseiten ersetzt werden : σAτ ⇒ σατ (A → α Produktion). 

Definition 11 

Sei G = (VN,VT,P,S) eine kontextfreie Grammatik. 

38


ϕ produziert ψ gemäß G direkt (ϕ ⇒G ψ) :⇔ es existieren Wörter σ,τ,α und ein 

Nichtterminal A mit ϕ = σAτ, ψ = σατ und A → α ∈ P. 

ϕ produziert ψ gemäß G (oder ψ ist aus ϕ gemäß G ableitbar) (ϕ ⇒ ∗ G ψ) :⇔ es 

existiert eine Folge von Wörtern ϕ1,...,ϕn(n ≥ 1) mit ϕ = ϕ1, ψ = ϕn und ϕi ⇒G 

ϕi+1 für 1 ≤ i < n. (⇒ ∗ G ist also die reflexive und transitive Hülle von ⇒G.) 

ϕ1,ϕ2,...,ϕn heißt dann eine Ableitung von ψ aus ϕ gemäß G. 

Wir schreiben auch ϕ ⇒ n−1 

G ψ (“in n − 1 Schritten”). 

Wenn aus dem Zusammenhang hervorgeht, auf welche Grammatik wir uns beziehen, 

lassen wir den Index G in ⇒G und ⇒ ∗ G weg. 

Beispiel 13 (Fortsetzung von Beispiel 10) 

Wir geben eine Ableitung des Wortes −(id+E) gemäß der in Beispiel 10 vorgestellten 

Grammatik an: 

E ⇒ −E ⇒ −(E) ⇒ −(EAE) ⇒ −(E + E) ⇒ −(id + E), 

also E ⇒ ∗ −(id + E). 

In einem Ableitungsschritt können mehrere anzuwendende Produktionen zur Auswahl 

stehen. So hätten wir im Schritt E ⇒ −E auch die Ableitung E ⇒ EAE 

auswählen können, was aber zur Folge hätte, daß wir das Wort −(id+E) nicht mehr 

hätten ableiten können. Ebenso kann eine Regel eventuell an verschiedenen Stellen 

des Wortes angewendet werden. So hätte im letzten Ableitungsschritt auch das Wort 

−(E + id) erzeugt werden können. 

Definition 12 

Die von G definierte (erzeugte) Sprache ist L(G) = {u ∈ V ∗ 

T | S ⇒ ∗ G u}. 

Ein Wort x ∈ L(G) heißt ein Satz von G. 

Ein Wort α ∈ (VN ∪ VT) ∗ mit S ⇒ ∗ G α heißt eine Satzform von G. 

In Beispiel 13 treten nur Satzformen, aber keine Sätze auf. 

Definition 13 

Eine kontextfreie Sprache ist eine Sprache, die von einer kontextfreien Grammatik 

erzeugt werden kann. Zwei kontextfreie Grammatiken G1,G2 heißen äquivalent :⇔ 

L(G1) = L(G2). 

Eine kontextfreie Grammatik enthält unter Umständen Nichtterminale, die nicht zur 

Erzeugung der Sprache beitragen. 

Definition 14 

39


• Ein Nichtterminal A heißt unerreichbar, wenn es keine Wörter α,β gibt mit 

S ⇒ ∗ αAβ. A heißt unproduktiv, wenn es kein Wort u gibt mit A ⇒ ∗ u. 

• Eine kontextfreie Grammatik G heißt reduziert, wenn sie weder unerreichbare 

noch unproduktive Nichtterminale enthält. 

Durch Elimination unerreichbarer und unproduktiver Nichtterminalsymbole aus der 

Grammatik entsteht eine äquivalente reduzierte Grammatik. Wir nehmen im folgenden 

immer an, daß die betrachteten Grammatiken reduziert sind. 

Definition 15 

Sei ϕ1,ϕ2,...,ϕn eine Ableitung von ϕ = ϕn aus S = ϕ1. 

ϕ1,ϕ2,...,ϕn heißt Linksableitung von ϕ (S ⇒ ∗ l ϕ), wenn beim Schritt von ϕi nach 

ϕi+1 jeweils das am weitesten links stehende Nichtterminal ersetzt wird. 

ϕ1,ϕ2,...,ϕn heißt Rechtsableitung von ϕ (S ⇒ ∗ r ϕ), wenn jeweils das am weitesten 

rechts stehende Nichtterminal ersetzt wird. 

Eine Satzform, die in einer Linksableitung (bzw. Rechtsableitung) auftritt, heißt Linkssatzform 

(bzw. Rechtssatzform). 


Die in Beispiel 13 angegebene Ableitung ist weder eine Links- noch eine Rechtsableitung. 

Allerdings kann das Wort −(id+E) auch mit folgender Linksableitung erzeugt 

werden: 

E ⇒l −E ⇒l −(E) ⇒l −(EAE) ⇒l −(id A E) ⇒l −(id + E), 

also gilt E ⇒ ∗ l −(id + E). 

Zu jedem Satz einer kontextfreien Grammatik gibt es eine Linksableitung und eine 

Rechtsableitung. Wir betrachten im folgenden nur Ableitungen, in deren Schritten 

entweder immer links oder immer rechts ersetzt wird. 

3.1.3 Strukturbäume 

Neben der Überprüfung der Fehlerfreiheit eines Programmtextes ist die Generierung 

einer Zwischendarstellung des Programms, die die syntaktische Struktur des Quelltextes 

wiedergibt, eine Aufgabe der syntaktischen Analyse. Diese Zwischendarstellung 

kann in den folgenden Phasen der Übersetzung verwendet werden. Dafür ist der 

Strukturbaum oder parse tree geeignet. 

Definition 16 

Sei G = (VN,VT,P,S) kontextfreie Grammatik. Sei B ein geordneter Baum, dessen 

Blätter über VN ∪ VT ∪ {ε} und dessen innere Knoten über VN markiert sind. 

B ist Strukturbaum für α ∈ (VN ∪ VT) ∗ und N ∈ VN, wenn gilt: 

40

- 

E 

E 

( E ) 

E A E 

id 

Abbildung 3.2: Beispiel eines Strukturbaums. 

+ 


1. Ist n innerer Knoten, der mit dem Nichtterminal A markiert ist, und sind 

seine Kinder von links nach rechts mit X1,...,Xk ∈ VN ∪ VT markiert, so ist 

A → X1...Xk ∈ P. Ist sein einziges Kind markiert mit ε, so ist A → ε ∈ P. 

2. Die Wurzel von B ist mit N markiert. 

3. Front (Wort an den Blättern) von B ist α. 

Ein Strukturbaum für ein Wort α und das Startsymbol S heißt Strukturbaum für α. 

Ein Strukturbaum für ein Wort u ∈ V ∗ 

T (alle seine Blätter sind mit Terminalen oder 

ε markiert) heißt vollständig. 

Beispiel 15 

In Abbildung 3.2 ist der Strukturbaum für die Ableitung aus Beispiel 14 dargestellt. 

Front des Baums ist die Satzform −(id+E). Der Strukturbaum ist nicht vollständig, 

da noch ein Blatt mit dem Nichtterminal E markiert ist. Wird dieses Blatt gemäß 

der Produktion E → id modifiziert, wird der Baum vollständig. 

Satz 3 

Jeder Satz einer kontextfreien Grammatik besitzt mindestens einen Strukturbaum. 

Beweis 

Der Satz besitzt eine Ableitung. Konstruiere dazu den Strukturbaum nach folgendem 

Verfahren. 

Sei ϕ1,ϕ2,...,ϕn eine Ableitung von α = ϕn aus N = ϕ1 gemäß G = (VN,VT,P,S). 

Dann existiert genau ein Strukturbaum für α und N gemäß G, der dieser Ableitung 

entspricht. 

41


E 

E 

- E 

- E 

- 

E 

E 

- E 

- 

( E ) ( E ) ( E ) 

E A E 

E A E 

E A 

id id + 

E 

E 

E 

( E ) 

Abbildung 3.3: Konstruktion eines Strukturbaums. 

Sei B 1 := N, also der Baum, der nur aus dem mit N markierten Knoten besteht. 

Sei B i−1 Strukturbaum für ϕi−1 (i > 1). Front von B i−1 ist ϕi−1. Sei ϕi−1 = 

X1X2...Xk ∈ (VN ∪ VT) ∗ . Sei ϕi aus ϕi−1 durch Ersetzen von Xj durch β = Y1Y2...Yl 

abgeleitet (also Xj → β ∈ P). 

Falls l > 0, sei B i der Baum, der aus B i−1 entsteht, indem das j-te Blatt (von links) 

l Nachfolgerknoten erhält, die von links nach rechts mit Y1,Y2,...,Yl markiert sind. 

Falls l = 0, erhält das j-te Blatt genau einen Nachfolger, der mit ε markiert wird. 

Der gesuchte Strukturbaum ist dann B := B n . 

� 

Beispiel 16 

Abbildung 3.3 enthält die schrittweise Konstruktion des Strukturbaums aus Abbildung 

3.2 gemäß der Ableitung aus Beispiel 14. 

Umgekehrt gilt: zu einem Strukturbaum gibt es mindestens eine Ableitung. Aber: 

ein Strukturbaum kann mehreren Ableitungen entsprechen (siehe obiges Beispiel). 

Allerdings gibt es zu jedem Strukturbaum für ein Wort w ∈ V ∗ 

T eine eindeutige 

Links- und eine eindeutige Rechtsableitung. 

3.1.4 Mehrdeutige Grammatiken 

Während aus einem Strukturbaum eindeutig hervorgeht, welchen Satz er beschreibt, 

kann es zu einem Satz mehrere Strukturbäume geben. Erlauben die Produktionen 

42 

E 

E

E 

E A E 

id 

+ 

E A E 

id 


E 

E A E 

E A E 

* id id + id 

Abbildung 3.4: Verschiedene Strukturbäume zu einem Satz. 

einer Grammatik zu einem Satz mehrere Strukturbäume, ist die Grammatik mehrdeutig. 

Beispiel 17 

In Abbildung 3.4 sind zwei mögliche Strukturbäume für den Satz id + id ∗ id gegeben. 

Ihre unterschiedliche Struktur ist in der Wahlmöglichkeit zwischen verschiedenen 

Produktionen begründet. Es entstehen verschiedene Strukturbäume, die trotzdem dieselbe 

Satzform als Ergebnis besitzen. 

Definition 17 

Ein Satz u ∈ L(G) heißt mehrdeutig, wenn er mehr als einen Strukturbaum hat. 

Eine kontextfreie Grammatik G heißt mehrdeutig, wenn L(G) mindestens einen 

mehrdeutigen Satz enthält. Eine nicht mehrdeutige Grammatik nennen wir eindeutig. 

Zu jedem eindeutigen Satz einer kontextfreien Grammatik gibt es genau eine Linksund 

genau eine Rechtsableitung. 

Manchmal ist es günstig, Mehrdeutigkeiten durch Umformen der Grammatik in eine 

äquivalente Grammatik zu eliminieren (andere Lösungsmöglichkeiten werden wir 

später betrachten). Diese Umformung ist aber nicht für jede beliebige Grammatik 

möglich, da es Sprachen gibt, die keine eindeutige Grammatik besitzen [AU72]. Außerdem 

muß beim Umformen darauf geachtet werden, daß die syntaktische Struktur 

der zu erkennenden Sprache nicht verändert wird. 

Beispiel 18 (“dangling else”) 

Die folgende Grammatik beschreibt eine if-Anweisung, bei der ein optionaler else- 

Zweig angegeben werden kann. 

stmt → if expr then stmt 

| if expr then stmt else stmt 

| other 

* 

id 

43


stmt 

if expr then stmt 

E 

1 

if expr then stmt else 

stmt 

E 

2 

S 

1 

S 

2 

if expr then stmt else stmt 

E 

1 


E 

2 

S 

1 

Abbildung 3.5: Mögliche Strukturbäume des “dangling else”-Problems. 

In Abbildung 3.5 sind zwei mögliche Strukturbäume für den Satz 

S 

2 

if E1 then if E2 then S1 else S2 

angegeben. Der obere Strukturbaum stellt eine Ableitung dar, in der zuerst die erste 

und dann die zweite Produktion der Grammatik angewendet wurden und das else 

somit zum zweiten if gehört. Im unteren Strukturbaum wurden zuerst die zweite 

und danach die erste Produktion angewendet und das else gehört daher zum ersten 

if. Beide Ableitungen sind aufgrund der Mehrdeutigkeit der Grammatik möglich. In 

Programmiersprachen (z.B. in Pascal) gilt aber die Konvention, daß ein else zum 

letzten noch freien then gehört. Daher stellt der obere Strukturbaum die gewünschte 

Ableitung dar. 

Um die Mehrdeutigkeit zu eliminieren, modifizieren wir die Grammatik. Dabei gehen 

wir von folgender Idee aus: die Anweisung zwischen einem then und einem else muß 

“geschlossen” sein, d.h. sie darf nicht mit einem freien then enden (sonst würde das 

else diesem then zugeordnet). Geschlossene Anweisungen (matched stmt) sind komplette 

if-then-else-Anweisungen, die nur geschlossene if-then-else-Anweisungen oder 

andere Anweisungen (dargestellt durch other) enthalten. Analog bezeichnen wir die 

nicht geschlossenen Anweisungen als unmatched stmt. Wir erhalten folgende Grammatik: 

44 

stmt

stmt 

unmatched_stmt 


E 

1 

matched_stmt 

if expr then matched_stmt else matched_stmt 

stmt 

matched_stmt 

E S S 

2 

1 2 

if expr then matched_stmt else matched_stmt 

(*) 

E S 

1 2 


Abbildung 3.6: Lösung des “dangling else”-Problems. 

stmt → matched stmt 

| unmatched stmt 

matched stmt → if expr then matched stmt else matched stmt 

| other 

unmatched stmt → if expr then stmt 

| if expr then matched stmt else unmatched stmt 

Diese Grammatik erzeugt dieselbe Sprache, läßt aber nur den ersten Strukturbaum 

zu (Abbildung 3.6). Im zweiten Strukturbaum in Abbildung 3.6 kann an der mit (*) 

markierten Position kein Teilbaum für if E2 then S1 eingefügt werden, da dort ein 

matched stmt erwartet wird. 

45


3.2 Konstruktion von Parsern 

Aus der Theorie der formalen Sprachen ist bekannt, daß nichtdeterministische Kellerautomaten 

genau die kontextfreien Sprachen erkennen [Sch08] (analog zu regulären 

Sprachen und endlichen Automaten). Also gibt es zu jeder kontextfreien Grammatik 

einen nichtdeterministischen Kellerautomaten. 

Im Gegensatz zu endlichen Automaten, bei denen die nichtdeterministischen und deterministischen 

Varianten die gleiche Mächtigkeit haben, besitzen nichtdeterministische 

Kellerautomaten eine größere Mächtigkeit als deterministische Kellerautomaten 

und erkennen somit mehr Sprachen als diese. Da wir Parser in Form eines Programms 

realisieren wollen, betrachten wir später Teilmengen der kontextfreien Sprachen, die 

sich mit deterministischen Kellerautomaten erkennen lassen. 

Im folgenden konstruieren wir zunächst nichtdeterministische Parser, die dann als 

Basis für deterministische Parse-Verfahren dienen. 

Es gibt zwei Konstruktionsverfahren eines nichtdeterministischen Kellerautomaten zu 

einer kontextfreien Grammatik. Entsprechend diskutieren wir zwei unterschiedliche 

Verfahren zur Konstruktion von Parsern. Beim Top-Down-Verfahren wird der Strukturbaum 

von der Wurzel zu den Blättern hin erzeugt, beim Bottom-Up-Verfahren 

entsprechend entgegengesetzt. 

3.2.1 Kellerautomat 

In Abbildung 3.7 ist das Schema eines nichtdeterministischen Kellerautomaten angegeben. 

Er besteht aus einer Kontrolleinheit, einem Keller für das Speichern von 

Werten, einem Eingabe- und einem Ausgabeband. Der Inhalt des Eingabebands wird 

mit dem Lesekopf zeichenweise von links nach rechts gelesen. In Abhängigkeit von 

dem gelesenen Zeichen und dem aktuellen Kellerinhalt führt die Kontrolleinheit einen 

Berechnungsschritt durch. Dabei können sowohl ein Zeichen auf das Ausgabeband 

geschrieben als auch der Inhalt des Kellers modifiziert werden. Hierbei wird immer 

an der Kellerspitze gelesen bzw. geschrieben. 

Definition 18 

Ein (nichtdeterministischer) Kellerautomat (mit Ausgabe) ist ein Tupel M = (Σ, Γ, ∆,z0,O) 

mit • Σ endliche Menge (Eingabealphabet), 

• Γ endliche Menge (Kelleralphabet), 

• zo ∈ Γ (Kellerstartsymbol), 

• O endliche Menge (Ausgabealphabet), 

• ∆ ⊆ ((Σ ∪ {ε}) × Γ) × (Γ ∗ × O ∗ ) (endliche Übergangsrelation). 

Jedes Element der Übergangsrelation beschreibt einen möglichen Schritt bei der Analyse 

des Eingabewortes. 

((Σ ∪ {ε}) × Γ) repräsentiert das aktuell vom Eingabeband gelesene Zeichen des 

46

Keller 

Eingabewort 

Kontrolle 

000 111 

3.2 Konstruktion von Parsern 

... 

Lesekopf 

Ausgabe 

Abbildung 3.7: Schema eines Kellerautomaten. 

Eingabealphabets Σ (ε falls keine Leseoperation durchgeführt wird) und das oberste 

Zeichen des Kellers (aus dem Kelleralphabet Γ). Bei der Durchführung eines Berechnungsschrittes 

(eines Übergangs des Kellerautomaten) wird die bisherige Kellerspitze 

entfernt und durch eine (evtl. auch leere) Folge von Kellerzeichen ersetzt sowie ein 

Zeichen auf das Ausgabeband geschrieben (repräsentiert durch (Γ ∗ × O ∗ )). 

Definition 19 

Sei M nichtdeterministischer Kellerautomat. 

Die Menge der Konfigurationen von M ist K = Σ ∗ × Γ ∗ × O ∗ . 

Die Anfangskonfiguration für die Analyse eines Wortes w ∈ Σ ∗ ist (w,z0,ε). 

Die Einzelschrittrelation ⊢M⊆ K × K ist definiert durch 

(aw,Y γ,u) ⊢M (w,βγ,ub) :⇔ ((a,Y ), (β,b)) ∈ ∆ (a ∈ Σ ∪ {ε}). ⊢ ∗ M ist die reflexive 

und transitive Hülle von ⊢M. 

Elemente von {ε} × {ε} × O ∗ heißen Endkonfigurationen. 

Die von M erkannte Sprache ist L(M) := {w ∈ Σ ∗ | (w,z0,ε) ⊢ ∗ M (ε,ε,σ), σ ∈ O ∗ }. 

Konfigurationen modellieren die Zustände während der Analyse eines Eingabewortes. 

Eine Konfiguration enthält die noch nicht gelesene Eingabe, den aktuellen Kellerinhalt 

und den Inhalt des Ausgabebandes. In der Anfangskonfiguration ist noch kein 

Zeichen der Eingabe gelesen, der Keller enthält nur das Kellerstartsymbol z0 und 

das Ausgabeband ist leer. Endkonfigurationen sind alle Konfigurationen, in denen 

Eingabeband und Keller leer sind und somit das Eingabewort komplett gelesen und 

der Kellerinhalt “verbraucht” wurde. Die Einzelschrittrelation beschreibt die Berechnungsschritte 

zwischen den Konfigurationen. (aw,Y γ,u) beschreibt den Zustand vor 

einem Schritt. Das aktuelle Symbol der Eingabe ist a ∈ Σ ∪ {ε}, die aktuelle Kellerspitze 

ist Y ∈ Γ und der Inhalt des Ausgabebands ist u ∈ O ∗ . Wenn es einen 

... 

47


Übergang ((a,Y ), (β,b)) in der Übergangsrelation ∆ des Kellerautomaten gibt, wird 

das a (eventuell ε) aus der Eingabe entfernt, die Kellerspitze Y wird durch ein Wort 

β ∈ Γ ∗ ersetzt und das Ausgabesymbol b wird an den bisherigen Inhalt des Ausgabebandes 

angehängt. Die von einem Kellerautomat erkannte Sprache ist die Menge 

der Wörter über dem Eingabealphabet, für die es eine Folge von Schritten von der 

entsprechenden Anfangskonfiguration in eine Endkonfiguration gibt. 

Wir erwähnten bereits, daß die Ausgabe eines Parsers ein Strukturbaum sein soll, der 

die syntaktische Struktur des Eingabeworts (also des Quellprogramms) darstellt. Aus 

diesem Grund müssen wir die Konstruktion des Strukturbaums in das Ausgabealphabet 

des Kellerautomaten, der den Parser realisiert, codieren. Da wir immer Linksoder 

Rechtsableitungen betrachten, genügt es bei der Konstruktion eines Strukturbaums, 

die Reihenfolge zu kennen, in der die Produktionen der Grammatik während 

der Analyse der Eingabe angewendet wurden. Daher ordnen wir den Produktionen 

der Grammatik eindeutige Nummern zu und definieren die Menge dieser Nummern 

als Ausgabealphabet des Kellerautomaten. 

Definition 20 

Sei π : {1, 2,...,p} → P bijektive Funktion (Numerierung der Produktionen der 

Grammatik). 

Sei z = z1z2...zn−1 ∈ {1,...,p} ∗ ,α ∈ (VN ∪ VT) ∗ . 

z heißt Linksanalyse von α, wenn S = ϕ1,ϕ2,...,ϕn = α Linksableitung von α und 

ϕi produziert ϕi+1 mit Regel zi. 

z heißt Rechtsanalyse von α, wenn S = ϕn,ϕn−1,...,ϕ1 = α Rechtsableitung von α 

und ϕi+1 produziert ϕi mit Regel zi. 

Eine Linksanalyse ist eine Ableitung S z1 z2 

⇒ ϕ2 ⇒ ... zn−2 

⇒ ϕn−1 ⇒ α. 

Eine Rechtsanalyse ist eine Ableitung S zn−1 zn−2 

⇒ ϕn−1 ⇒ ... z2 z1 

⇒ ϕ2 ⇒ α, enthält also die 

Regelnummern einer Rechtsableitung in umgekehrter Reihenfolge. 

Wir nehmen im folgenden an, daß die Produktionen der Grammatiken mit Regelnummern 

versehen sind. 

Es gibt zwei verschiedene Verfahren zur Analyse eines Wortes mit Kellerautomaten: 

• “Top-Down”: Dieses Verfahren entspricht der Konstruktion eines Strukturbaums 

von der Wurzel ausgehend. Diese Konstruktion realisiert eine Linksableitung, 

daher ist die Ausgabe des Parsers eine Linksanalyse. 

• “Bottom-Up”: Dieses Verfahren entspricht der Konstruktion eines Strukturbaums 

von den Blättern ausgehend. Diese Konstruktion realisiert eine Rechtsableitung 

in umgekehrter Reihenfolge; die Ausgabe des Parsers ist also eine 

Rechtsanalyse. 

In den folgenden Abschnitten werden die beiden Parse-Verfahren erläutert. 

48 

zn−1

3.3 Top-Down-Syntaxanalyse 


Zunächst konkretisieren wir den in Definition 18 eingeführten Kellerautomaten für 

die Top-Down-Analyse. 

Notation: Für ein Alphabet Σ sei Σ ≤k = � 

0≤i≤k Σ i die Menge der Wörter mit der 

maximalen Länge k (einschließlich ε). 

Definition 21 

Ein (nichtdeterministischer) Top-Down-Analyseautomat für eine kontextfreie Grammatik 

G = (VN,VT,P,S) ist ein Kellerautomat mit 

• Eingabealphabet VT, 

• Kelleralphabet Γ = VN ∪ VT, 

• Kellerstartsymbol S, 

• Ausgabealphabet {1,...,p}, 

• Übergangsrelation ∆ ⊆ ((VT ∪ {ε}) × Γ) × (Γ ∗ × {1,...,p} ≤1 ), wobei 

((ε,A), (α,i)) ∈ ∆ :⇔ π(i) = A → α und 

((a,a), (ε,ε)) ∈ ∆ für alle a ∈ VT. 

Die Übergangsrelation ∆ enthält zwei Arten von Regeln: 

1. Die Regeln der Form ((ε,A), (α,i)) beschreiben die Anwendung der i-ten Produktion 

der Grammatik. Befindet sich das Nichtterminal A der Produktion 

A → α auf dem Keller, wird dieses Symbol vom Keller entfernt und durch die 

rechte Seite α der Produktion ersetzt, so daß das erste Zeichen von α die neue 

Kellerspitze darstellt. Dabei wird kein Zeichen aus der Eingabe gelesen. Auf das 

Ausgabeband wird die Nummer i der ausgewählten Produktion geschrieben. 

2. Für jedes Terminalsymbol a ∈ VT wird eine Regel der Form ((a,a), (ε,ε)) in die 

Übergangsrelation aufgenommen. Ist das aktuelle Symbol der Eingabe gleich 

der aktuellen Kellerspitze, werden beide Zeichen entfernt und das Ausgabeband 

bleibt unverändert, da keine Produktion der Grammatik angewendet wurde. 

Diese beiden Arten von Regeln definieren die Arbeitsweise des Top-Down-Parsers. 

Mit den Regeln unter 1) stellt der Parser Hypothesen auf, wie der folgende Abschnitt 

des Programmtextes aussieht, indem er Nichtterminale auf dem Keller durch 

die zugehörigen rechten Regelseiten ersetzt. Mit den unter 2) beschriebenen Regeln 

werden diese Hypothesen überprüft, indem übereinstimmende Zeichen der Eingabe 

und des Kellers paarweise gelöscht werden. Ist die Eingabe komplett gelesen und der 

Keller leer, d.h. jedes Symbol der Eingabe konnte einem Kellersymbol zugeordnet 

werden, akzeptiert der Automat die Eingabe als Wort der zu erkennenden Sprache. 

49


Eingabe Kellerinhalt Ausgabe 

- ( id + id ) E 

- ( id + id ) - E 3 

( id + id ) E ε 

( id + id ) ( E ) 2 

id + id ) E ) ε 

id + id ) E A E ) 1 

id + id ) id A E ) 4 

+ id ) A E ) ε 

+ id ) + E ) 5 

id ) E ) ε 

id ) id ) 4 

) ) ε 

ε ε ε 

Tabelle 3.1: Beispielableitung eines Top-Down-Parsers. 

Beispiel 19 (Top-Down-Analyse arithmetischer Ausdrücke) 

Gegeben sei die folgende Grammatik zur Definition vereinfachter arithmetischer Ausdrücke 

mit Nummerierung der Produktionen: 

E → E A E (1) 

| ( E ) (2) 

| - E (3) 

| id (4) 

A → + (5) 

| - (6) 

| * (7) 

| / (8) 

| ↑ (9) 

Eine Top-Down-Ableitung des Satzes -(id+id) ist in Tabelle 3.1 angegeben. Die linke 

Spalte enthält die noch nicht gelesene Eingabe, die mittlere den aktuellen Kellerinhalt 

(mit der Kellerspitze links) und die rechte das Zeichen, das in dem jeweiligen Schritt 

auf das Ausgabeband geschrieben wird. Dieses Zeichen ist entweder die Nummer der 

angewendeten Produktion oder ε, falls das Symbol aus der Eingabe der aktuellen 

Kellerspitze entspricht und beide Symbole daher gelöscht werden können. 

Aufgrund des Nichtdeterminismus könnten auch jeweils andere Reihenfolgen der Produktionen 

bzw. andere Produktionen gewählt werden, wodurch das Eingabewort gegebenenfalls 

nicht erkannt werden würde. 

50


Die Symbole in der Ausgabe-Spalte der Tabelle bilden eine Linksanalyse des Satzes 

-(id+id): 

E 3 ⇒ - E 2 ⇒ - ( E ) 1 ⇒ - ( E A E ) 4 ⇒ - ( id A E ) 5 ⇒ - ( id + E ) 

4 

⇒ - ( id + id ) 

Gemäß der Ausgabe der jeweils angewendeten Regel läßt sich der Strukturbaum 

schrittweise konstruieren (siehe Abbildung 3.8). 

3.3.1 LL(k)-Grammatiken 

Die Auswahl der anzuwendenden Produktion in einer Konfiguration ist aufgrund des 

Nichtdeterminismus nicht eindeutig, so daß die “richtige” Produktion unter mehreren 

Alternativen geraten werden muß. Eine deterministische Auswahl könnte durch die 

Integration von backtracking in den Parser erreicht werden. Allerdings ist backtracking 

unter dem Gesichtspunkt der Effizienz ungeeignet. 

Eine Ursache für den Nichtdeterminismus ist, daß die Eingabe erst nach der Auswahl 

einer Produktion mit dem Inhalt des Stacks verglichen wird. Daher werden wir Verfahren 

betrachten, die bei der Auswahl einer Produktion einen begrenzten Ausschnitt 

der Eingabe berücksichtigen und auf diese Weise die Auswahl deterministisch treffen 

können. 

Das Konzept der LL(k)-Grammatiken beruht auf dieser Berücksichtigung eines Teils 

der Eingabe bei der Auswahl der Produktionen. Das Vorausschauen in der Eingabe 

wird lookahead genannt. Bei einer LL(k)-Grammatik genügt ein lookahead von k 

Symbolen in der Eingabe, um beim deterministischen Top-Down-Parseverfahren die 

Produktionen auszuwählen (das erste L bedeutet, daß die Eingabe von links gelesen 

wird, das zweite L, daß eine Linksableitung konstruiert wird). Die LL(k)-Sprachen 

sind mit einer Top-Down-Analyse deterministisch zu erkennen. Allerdings bilden die 

LL(k)-Sprachen nur eine Teilmenge der kontextfreien Sprachen. Nicht alle kontextfreien 

Sprachen können durch LL(k)-Grammatiken beschrieben werden. 

Definition 22 

Sei Σ Alphabet, w = a1...an ∈ Σ ∗ (n ≥ 0), k ≥ 0. 

ist der k-Präfix von w. 

k : w = 

� 

w falls n ≤ k 

a1...ak sonst 

Definition 23 

Sei G = (VN,VT,P,S) kontextfreie Grammatik, k ≥ 0. G ist eine LL(k)-Grammatik, 

wenn gilt: 

51


1 

4 

E 

E 

- E 

- E 

- 

- 

E 

( E ) ( E ) ( E ) 

E A E 

E A E 

E A 

E 

E 

( E ) 

E A E 

id + id 

E 

3 2 

- E 

- 

4 5 

id id + 

E 

E 

E 

( E ) 

Abbildung 3.8: Konstruktion des Strukturbaums anhand der Ausgabe des Parsers. 

52 

E 

E

S ⇒ ∗ l u Y α 

⇒l u β α ⇒ ∗ l u x 

⇒l u γ α ⇒ ∗ l u y 


und k : x = k : y, dann β = γ (d.h. die Alternative der Auswahl der Produktion für 

jedes Nichtterminal Y ist durch die ersten k Zeichen der restlichen Eingabe eindeutig 

festgelegt (bei festem Linkskontext u)). 

Beispiel 20 

Die Grammatik G1, gegeben durch die Produktionen 

stmt → if id then stmt else stmt fi 

| while id do stmt od 

| begin stmt end 

| id : = id 

ist eine LL(1)-Grammatik (wir betrachten in diesem Beispiel das Zuweisungssymbol 

:= als zwei separate Symbole : und =). 

Wann immer stmt in einer Ableitung auftritt, ist aufgrund des nächsten Eingabesymbols 

klar, welche Produktion anzuwenden ist. Die abzuleitenden Folgen von Terminalsymbolen 

beginnen alle mit unterschiedlichen Symbolen (if, while, begin oder 

id), so daß mit einem lookahead von 1 die anzuwendende Produktion eindeutig zu 

bestimmen ist. 

Eine solche Grammatik, bei der die rechten Seiten der Produktionen zu einem Nichtterminalsymbol 

alle mit unterschiedlichen Terminalsymbolen beginnen, heißt einfache 

LL(1)-Grammatik. 

Definition 24 

Sei G kontextfreie Grammatik ohne ε-Produktionen. Beginnt für jedes Nichtterminal 

N jede seiner Alternativen mit einem anderen Terminalsymbol, dann heißt G einfache 

LL(1)-Grammatik. 

Einerseits ist die Zugehörigkeit einer Grammatik zur Klasse der einfachen LL(1)- 

Grammatiken sehr einfach zu überprüfen, andererseits sind diese Grammatiken für 

die Praxis i. allg. zu eingeschränkt. 


Wir erweitern G1 zu G2 durch die zusätzlichen Produktionen 

stmt → id : stmt (* markierte Anweisung *) 

| id ( id ) (* Prozeduraufruf *) 

G2 ist nicht mehr einfach LL(1), denn mehrere Alternativen für stmt beginnen nun 

mit dem Terminalsymbol id. 

G2 ist auch nicht mehr LL(1): 

53


⇒l u id : = id α ⇒ ∗ l u x 

stmt ⇒ ∗ l u stmt α ⇒l u id : stmt α ⇒ ∗ l u y 

⇒l u id ( id ) α ⇒ ∗ l u z 

In den drei Satzformen ist der Anfang “u id” gleich, so daß nicht durch einen lookahead 

von 1 entschieden werden kann, welche Produktion anzuwenden ist. 

G2 ist auch keine LL(2)-Grammatik, da in den oberen beiden Satzformen die Anfangsstücke 

“u id :” identisch sind und daher auch durch einen lookahead von 2 die 

Auswahl nicht deterministisch getroffen werden kann. Wenn wir jedoch den Zuweisungsoperator 

:= als ein einzelnes Symbol betrachten, ist G2 eine LL(2)-Grammatik. 

Es gibt kontextfreie Grammatiken, die keine LL(k)-Grammatiken sind, auch wenn 

wir k beliebig groß wählen. Manchmal kann man eine solche Grammatik in eine 

äquivalente LL(k)-Grammatik transformieren. Allerdings gibt es auch kontextfreie 

Grammatiken, für die es keine äquivalente LL(k)-Grammatik für irgendein k gibt. 

Für praktische Zwecke, d.h. für die Beschreibung der Syntax der bekannten Programmiersprachen, 

gibt es fast immer LL(1)- oder LL(2)-Grammatiken. 

Wie können wir überprüfen, ob eine Grammatik LL(k) ist, ohne alle möglichen Ableitungen 

zu betrachten? 

Ein Hilfsmittel hierzu sind die sogenannten FIRST-Mengen. Diese Mengen beschreiben, 

mit welchen Anfangsstücken aus Satzformen herleitbare Terminalworte beginnen 

können. 

Definition 25 

Sei G = (VN,VT,P,S) kontextfreie Grammatik, k ∈ INI. 

FIRSTk : (VN ∪ VT) ∗ → P(V ≤k 

T ) ist definiert durch 

FIRSTk(α) = {k : w | α ⇒ ∗ w}. 

FIRSTk(α) ist also die Menge der Anfangsstücke der Länge k von Terminalwörtern, 

die aus α ableitbar sind. Falls kürzere Wörter ableitbar sind, dann sind diese auch 

in der FIRST-Menge enthalten, insbesondere eventuell auch ε. 

Mit Hilfe der FIRST-Mengen läßt sich die Klasse der LL(k)-Sprachen wie folgt 

charakterisieren: 

Satz 4 (LL(k)-Charakterisierung) 

Sei G = (VN,VT,P,S) kontextfreie Grammatik, k ≥ 0. G ist genau dann LL(k), 

wenn gilt: 

Sind A → β,A → γ verschiedene Produktionen in P, dann FIRSTk(βα)∩FIRSTk(γα) = 

∅ für alle α, u mit S ⇒ ∗ l uAα. 

54


Beweis 

“⇒”: 

Annahme: G ist LL(k) und es existiert x ∈ FIRSTk(βα) ∩ FIRSTk(γα). Nach 

Definition 25 und da G reduziert: 

S ⇒ ∗ l u A α 

⇒l u β α ⇒ ∗ l u x y 

⇒l u γ α ⇒ ∗ l u x z 

(xy und xz bis zur Länge k oder ganz identisch; falls Länge von x ≤ k, dann y = 

z = ε). 

Da aber β �= γ (da A → β, A → γ verschiedene Produktionen), wäre G nicht LL(k), 

was aber ein Widerspruch zur Annahme darstellt. 

“⇐”: 

Annahme: G ist nicht LL(k) und FIRSTk(βα) ∩ FIRSTk(γα) = ∅ für alle α mit 

S ⇒ ∗ l uAα. Dann gibt es (da G reduziert) 

S ⇒ ∗ l u A α 

⇒l u β α ⇒ ∗ l u x 

⇒l u γ α ⇒ ∗ l u y 

mit k : x = k : y, wobei A → β,A → γ verschiedene Produktionen. Aber k : x = k : 

y ∈ FIRSTk(βα) ∩ FIRSTk(γα), was einen Widerspruch zur Annahme darstellt. 

� 

Aus dieser Charakterisierung sind weitere Kriterien für die Zugehörigkeit zu LL(k) 

ableitbar. Wir betrachten hier nur den für die Praxis besonders wichtigen Fall k = 1. 

Sei k = 1 und G eine kontextfreie Grammatik ohne ε-Produktionen. Dann sind 

FIRST1(βα) ∩ FIRST1(γα) allein aus β und γ bestimmbar (da β und γ aufgrund 

der fehlenden ε-Produktionen nicht leer werden können und daher mindestens ein 

Zeichen generieren). 

Satz 5 

Sei G kontextfreie Grammatik ohne ε-Produktionen. G ist LL(1) genau dann, wenn 

für jedes Nichtterminal A mit A → α1 | ... | αn (A hat genau die Alternativen α1, 

..., αn) gilt: FIRST1(α1), ..., FIRST1(αn) paarweise disjunkt. 

Da ε-Produktionen in Grammatiken von Programmiersprachen üblicherweise auftreten, 

bedeutet das generelle Verbot von ε-Produktionen eine zu starke Einschränkung. 

Durch das Zulassen dieser Produktionen ist das Kriterium aus Satz 5 nicht mehr ausreichend. 

Dies wird im folgenden Beispiel verdeutlicht. 

Beispiel 22 

Wir betrachten eine kontextfreie Grammatik G mit folgenden Produktionen: 

55


Strukturbaum lookahead 

S a 

S 

A a 

A 

a 

S 

a 

Abbildung 3.9: Fehlerhafte Konstruktion eines Strukturbaums für die Eingabe a. 

S → A a 

A → a | ε 

Offensichtlich sind die FIRST1-Mengen der Alternativen der Nichtterminale disjunkt. 

Aber G ist nicht LL(1) gemäß Satz 4, denn mit α = a, β = a und γ = ε gilt: 

FIRST1(βα) ∩ FIRST1(γα) = FIRST1(aa) ∩ FIRST1(εa) = {a} �= ∅. 

Was würde beim Top-Down-Parsen passieren? In Abbildung 3.9 wird die schrittweise 

Konstruktion des Strukturbaums für das Eingabewort a dargestellt. Im ersten Schritt 

wird die erste Produktion angewendet. Diese Auswahl ist eindeutig, da das Startsymbol 

nur eine Alternative besitzt. Im zweiten Schritt muß das A abgeleitet werden. 

Dieses Nichtterminal besitzt zwei Alternativen. Durch einen Vergleich mit dem lookahead, 

der das a enthält, kann sich der Parser für die erste Alternative von A 

entscheiden. Der so konstruierte Syntaxbaum entspricht aber nicht dem Eingabewort 

a, sondern dem Satz aa. Der Parser hätte das A zu ε ableiten müssen. 

Das Problem bei der deterministischen Auswahl der Produktionen von A entsteht, 

da in der Produktion S → Aa das a auf A folgt. Betrachten wir noch einmal den 

Charakterisierungssatz (Satz 4) mit k = 1. Angenommen, es gilt β ⇒ ∗ ε. Falls 

auch γ ⇒ ∗ ε gilt, ist die Grammatik nicht LL(k), da der Parser durch keinen lookahead 

eine Entscheidung treffen kann. Wenn γ ⇒ ∗ ε nicht gilt, muß die Bedingung 

FIRST1(α) ∩ FIRST1(γ) = ∅ gelten für alle S ⇒ ∗ l uAα. Wir betrachten also alle 

möglichen Anfänge von dem, was auf A folgen kann. Hierzu definieren wir die sogenannten 

FOLLOW-Mengen. 

56 

a

Definition 26 

Sei G = (Vn,VT,P,S) kontextfreie Grammatik, k ∈ INI. 

FOLLOWk : (VN ∪ VT) ∗ → P(V ≤k 

T ) ist definiert durch 

FOLLOWk(α) = {w | S ⇒ ∗ βαγ und w ∈ FIRSTk(γ)}. 


Insbesondere werden wir FOLLOW-Mengen für einzelne Nichtterminale betrachten. 

Für k = 1 bezeichnet FOLLOW1(A) die Menge der Terminale a, die in einer Ableitung 

auf das Nichtterminal A folgen können. Hierbei ist zu beachten, daß zwischen 

A und a während der Ableitung auch Nichtterminale gestanden haben können, die 

zu ε abgeleitet wurden. 

Mit Hilfe der FOLLOW1-Mengen können wir Satz 5 auf Grammatiken mit ε-Produktionen 

erweitern. 

Satz 6 

Eine kontextfreie Grammatik G ist genau dann LL(1), wenn für alle Alternativen 

A → α1 | ... | αn gilt: 

1. FIRST1(α1), ..., FIRST1(αn) paarweise disjunkt (insbesondere enthält nur 

eine dieser Mengen ε), 

2. falls αi ⇒ ∗ ε, dann FIRST1(αj) ∩ FOLLOW1(A) = ∅ für alle 

1 ≤ j ≤ n,j �= i. 

Wir geben nun die Algorithmen für die Berechnung von FIRST1- und FOLLOW1- 

Mengen an. 

Berechnung von FIRST1-Mengen: Sei G = (VN,VT,P,S) kontextfreie Grammatik. 

• Sei X ∈ VN ∪ VT. FIRST1(X) ist die kleinste Menge mit 

1. falls X Terminal, dann FIRST1(X) = {X}, 

2. falls X → ε ∈ P, dann ε ∈ FIRST1(X), 

3. falls X → Y1Y2...Yk ∈ P: 

– Terminalsymbol a ∈ FIRST1(X), wenn a ∈ FIRST1(Yi) und ε ∈ 

FIRST1(Yj) für 1 ≤ j < i, 

– ε ∈ FIRST1(X), wenn ε ∈ FIRST1(Yj) für 1 ≤ j ≤ k. 

• Sei α ∈ (VN ∪ VT) ∗ , α = X1X2...Xn. FIRST1(α) ist die kleinste Menge mit 

– FIRST1(X1)\{ε} ⊆ FIRST1(α), 

– falls ε ∈ FIRST1(X1), dann FIRST1(X2)\{ε} ⊆ FIRST1(α), 

– ... 

57


– falls ∀i, 1 ≤ i ≤ n − 1 : ε ∈ FIRST1(Xi), dann FIRST1(Xn)\{ε} ⊆ 

FIRST1(α), 

– falls ∀i, 1 ≤ i ≤ n : ε ∈ FIRST1(Xi), dann ε ∈ FIRST1(α) (beachte, daß 

hier insbesondere FIRST1(ε) = {ε} folgt). 

Berechnung von FOLLOW1-Mengen: Sei G = (VN,VT,P,S) kontextfreie Grammatik. 

Zur Berechnung der FOLLOW1-Mengen werden simultan für alle Nichtterminale 

der Grammatik folgende Schritte durchgeführt: 

1. ε ∈ FOLLOW1(S), 

2. A → αBβ ∈ P, a ∈ FIRST1(β), dann a ∈ FOLLOW1(B) für a ∈ VT. 

3. A → αBβ ∈ P und ε ∈ FIRST1(β) (d.h. β ⇒ ∗ ε, evtl. sogar β = ε), 

dann FOLLOW1(A) ⊆ FOLLOW1(B). 

Manchmal wird ein spezielles Symbol $ �∈ VT verwendet, das an das Eingabewort 

angehängt wird und während der Analyse zur Erkennung des Eingabeendes dient. In 

diesem Fall wird Regel 1 durch $ ∈ FOLLOW(S) ersetzt. 

Im folgenden lassen wir den Index 1 bei den FIRST1- und FOLLOW1-Mengen weg. 


Wir betrachten die Grammatik aus Beispiel 22 mit den folgenden Produktionen: 

S → A a 

A → a | ε 

• Berechnung von FIRST(S): 

Wir betrachten S → Aa und stellen fest, daß wir die Menge FIRST(A) benötigen. 

Aufgrund der Regeln für ein Nichtterminal A erhalten wir: a ∈ FIRST(A) 

und ε ∈ FIRST(A). Da a ∈ FIRST(A), gilt auch a ∈ FIRST(S). Wegen 

ε ∈ FIRST(A) muß auch die FIRST-Menge des a in S → Aa in die FIRST- 

Menge von S aufgenommen werden. Da FIRST(a) = {a}, ε /∈ FIRST(a) und 

a bereits in FIRST(S), bleibt FIRST(S) unverändert: FIRST(S) = {a}. 

• Berechnung der FOLLOW-Mengen: 

Nach Regel 1 gilt ε ∈ FOLLOW(S). Nach Regel 2 gilt a ∈ FOLLOW(A), da A 

in S → Aa auftritt und a ∈ FIRST(a). Weitere Auftreten von Nichtterminalen 

in rechten Regelseiten kommen nicht vor. Die Regel 3 kann nicht angewendet 

werden, also gilt FOLLOW(A) = {a}. 

Damit gilt a ∈ FIRST(a) ∩ FOLLOW(A) und somit ist die zweite Bedingung von 

Satz 6 nicht erfüllt. Also ist die Grammatik nicht LL(1). 

58

3.3.2 Transformierung von Grammatiken 


Es gibt zwei Klassen von kontextfreien Grammatiken, die in der Praxis zur Definition 

der Syntax von Programmiersprachen verwendet werden, aber nicht LL(k) sind für 

beliebiges k. Dabei handelt es sich zum einen um mehrdeutige Grammatiken und 

zum anderen um linksrekursive Grammatiken. 

Mehrdeutige Grammatiken wurden bereits in Abschnitt 3.1.4 eingeführt. 

Satz 7 

Sei G kontextfreie Grammatik. Ist G mehrdeutig, ist G nicht LL(k) für jedes k ≥ 0. 

Beweis 

Der Beweis folgt unmittelbar aus der Definition von LL(k). Wenn ein Terminalwort 

durch unterschiedliche Linksableitungen zu erkennen ist, kann die Auswahl zwischen 

Alternativen nicht durch irgendeinen lookahead entschieden werden. � 

Linksrekursive Grammatiken 

Definition 27 

Sei G kontextfreie Grammatik. 

Eine Produktion von G heißt direkt rekursiv, wenn sie die Form A → αAβ hat. Sie 

heißt direkt linksrekursiv, wenn α = ε, direkt rechtsrekursiv, wenn β = ε. 

Ein Nichtterminal A heißt rekursiv, wenn es eine Ableitung A ⇒ + αAβ gibt (⇒ + ist 

die transitive Hülle von ⇒, d.h. es muß mindestens ein Ableitungsschritt durchgeführt 

worden sein). A heißt linksrekursiv, wenn α = ε, rechtskursiv, wenn β = ε. 

G heißt linksrekursiv, wenn G mindestens ein linksrekursives Nichtterminal enthält, 

rechtsrekursiv, wenn G mindestens ein rechtsrekursives Nichtterminal enthält. 

Satz 8 

Sei G kontextfreie Grammatik. Ist G linksrekursiv, ist G nicht LL(k) für jedes k ≥ 0. 

Beweisskizze 

Wir betrachten hier nur den Fall k = 1 und die direkte Linksrekursion. 

G sei eine direkt linksrekursive Grammatik, d.h. G enthält eine Produktion der Form 

A → Aβ. Da G reduziert ist, gibt es außerdem eine weitere Produktion A → γ des 

Nichtterminals A. Wir unterscheiden zwei Fälle: 

• FIRST(γ) �= {ε}. Dann gilt FIRST(γ) ∩ FIRST(Aβ) �= ∅, da Aβ nach γβ 

abgeleitet werden kann. Nach Bedingung 1 von Satz 4 ist G daher keine LL(1)- 

Grammatik. 

• FIRST(γ) = {ε}. Dann muß nach Bedingung 1 von Satz 6 gelten, daß ε �∈ 

FIRST(Aβ). Nach Bedingung 2 muß gelten: FIRST(Aβ)∩FOLLOW(A) = ∅. 

59


Es gilt aber: ∃a ∈ FIRST(β) (da sonst ε ∈ FIRST(Aβ)) und a ∈ FOLLOW(A), 

also ist a ∈ FIRST(Aβ) (da ε ∈ FIRST(γ) und daher auch ε ∈ FIRST(A)). 

Also ist G nicht LL(1). 

� 

Ein Beispiel, in dem Linksrekursion auftritt, ist die Definition der Syntax arithmetischer 

Ausdrücke. 

Beispiel 24 

Die folgende Grammatik beschreibt arithmetische Ausdrücke mit den Operatoren + 

und ∗ unter Berücksichtigung der korrekten Operatorprioritäten: 

E → E + T | T 

T → T * F | F 

F → ( E ) | id 

Die Nichtterminale E und T sind linksrekursiv. Daher ist diese Grammatik für kein 

k ≥ 0 eine LL(k)-Grammatik. 

Linksrekursion kann durch Transformation der Grammatik in eine äquivalente Grammatik 

eliminiert werden. Wir erläutern diese Transformation am Beispiel der direkten 

Linksrekursion. 

Transformation einer linksrekursiven in eine rechtsrekursive Grammatik 

Gegeben seien die Produktionen A → Aα|β (in Beispiel 24 etwa A = E,α = +T,β = 

T). Diese Produktionen erzeugen einen Strukturbaum wie in der oberen Hälfte von 

Abbildung 3.10 angegeben. 

Wir ersetzen die obigen Produktionen für A durch 

A → β A’ 

A’ → α A’ | ε 

mit dem neuen Nichtterminal A ′ . Diese neue Grammatik ist rechtsrekursiv, was auf 

die LL(k)-Eigenschaft keinen Einfluß hat. Der entsprechende Strukturbaum ist in 

ebenfalls in Abbildung 3.10 dargestellt. 

Durch diese Transformation entstehen zusätzliche ε-Produktionen. 


Die Transformation der Grammatik aus Beispiel 24 ergibt die folgende rechtsrekursive 

Grammatik: 

60

A 

A 

A 

β α α α 

A 

A’ 

A’ 

A 

A’ 


A’ 

β α α α ε 

Abbildung 3.10: Transformation in rechtsrekursive Grammatik. 

E → T E’ 

E’ → + T E’ | ε 

T → F T’ 

T’ → * F T’ | ε 

F → ( E ) | id 

Linksfaktorisierung 

Eine weitere Möglichkeit, Grammatiken, die nicht die LL(k)-Eigenschaft besitzen, 

in eine äquivalente LL(k)-Grammatik zu transformieren, ist die Linksfaktorisierung. 

Dieses Verfahren beruht auf der Idee, die Entscheidung über die Auswahl der Regel 

hinauszuschieben. Dabei werden die gleichen Anfänge der Produktionen eines 

Nichtterminals zu einer Produktion zusammengefaßt. Produktionen der Form 

werden ersetzt durch 

A → αβ1 | αβ2 

61


A → αA ′ 

A ′ → β1 | β2 

Der folgende Algorithmus führt eine Linksfaktorisierung durch. 

Algorithmus Linksfaktorisierung. 

Eingabe: Grammatik G 

Ausgabe: Äquivalente linksfaktorisierte Grammatik 

Verfahren: 

Für jedes Nichtterminalsymbol A: Bestimme längstes gemeinsames Präfix α 

zweier oder mehrerer rechter Seiten für A. Falls α �= ε, ersetze 

A → αβ1 | αβ2 | ... | αβn | γ 

(wobei γ für alle nicht mit α beginnenden rechten Seiten steht) durch 

A → αA ′ | γ 

A ′ → β1 | β2 | ... | βn 

(mit A ′ neues Nichtterminalsymbol). Wiederhole diese Transformation solange, 

bis es keine Alternativen mit gemeinsamen Präfixen mehr gibt. 

Beispiel 26 

Wir betrachten erneut das dangling-else-Problem. Wir geben die Produktionen der 

Grammatik in verkürzter Schreibweise an: 

S → i E t S | i E t S e S | a 

E → b 

Diese Grammatik ist nicht LL(1), da die ersten beiden Produktionen von S identische 

Präfixe i E t S besitzen und daher eine Auswahl der Alternative nicht möglich ist. 

Die Anwendung der Linksfaktorisierung ergibt die folgende äquivalente Grammatik: 

S → i E t S S’ | a 

S’ → e S | ε 

E → b 

In dieser Grammatik tritt das gemeinsame Präfix nur noch in einer Produktion 

auf, so daß bei der Auswahl der Produktionen von S mit einem lookahead von 1 

eine Entscheidung getroffen werden kann. Allerdings ist die neue Grammatik immer 

noch nicht LL(1), da für die Produktionen von S ′ gilt: ε ∈ FIRST(ε) und 

e ∈ FIRST(eS) ∩ FOLLOW(S ′ ), da FOLLOW(S) ⊆ FOLLOW(S ′ ). Die Grammatik 

kann die LL(1)-Bedingung nicht erfüllen, da sie mehrdeutig ist (siehe Abschnitt 

3.3.2). 

62

Parse-Tabellen 


Wir haben in den letzten Abschnitten gezeigt, daß mit Hilfe der LL(k)-Grammatiken 

eine deterministische Top-Down-Analyse der Eingabe möglich ist. Nun geben wir ein 

Verfahren an, wie wir zu einer gegebenen LL(1)-Grammatik einen deterministischen 

Parser bauen können. Hierzu werden die Parse-Tabellen verwendet. 

Eine Parse-Tabelle M für eine kontextfreie Grammatik G gibt an, welche Produktion 

für ein Nichtterminalsymbol bei einem bestimmten lookahead in Frage kommt. 

Die Zeilen der Tabelle sind mit den Nichtterminalen der Grammatik beschriftet, die 

Spalten mit den Terminalsymbolen und dem Endezeichen $. M[A,a] enthält dann die 

bei lookahead a anzuwendende Produktion für A bzw. error, falls keine Produktion 

von A unter dem aktuellen lookahead a anwendbar ist. 

Das folgende Verfahren wird zur Konstruktion einer LL(1)-Parse-Tabelle angewendet. 

Konstruktion der Parse-Tabelle zu einer Grammatik. 

Eingabe: Grammatik G mit FIRST- und FOLLOW-Mengen 

Ausgabe: Parse-Tabelle M für G 

Verfahren: 

1. Für jede Produktion A → α von G: 

a) Für jedes a ∈ FIRST(α),a �= ε: trage A → α in M[A,a] ein. 

b) Falls ε ∈ FIRST(α): für jedes b ∈ FOLLOW(A): trage A → α in 

M[A,b] ein (wobei b Terminalsymbol oder $). 

2. Trage in jedes noch undefinierte Feld error ein. 

Beispiel 27 

Wir betrachten die Grammatik aus Beispiel 25: 

E → T E’ 

E’ → + T E’ | ε 

T → F T’ 

T’ → * F T’ | ε 

F → ( E ) | id 

Wir konstruieren schrittweise die Parse-Tabelle aus Tabelle 3.2. 

Wir beginnen mit dem Startsymbol E. Im ersten Schritt berechnen wir die FIRST- 

Mengen der rechten Regelseiten von E, in diesem Fall also 

FIRST(T E ′ ) = FIRST(T) = FIRST(F T ′ ) = FIRST(F) = {(,id} (weder 

FIRST(T) noch FIRST(F) enthalten ε). Wir tragen also in die Spalten, die mit 

Terminalsymbolen aus FIRST(T E ′ ) beschriftet sind, die Produktion E → T E ′ ein. 

Da ε /∈ FIRST(T E ′ ), ist der Schritt (1b) für diese Produktion nicht anwendbar. 

63


id + * ( ) $ 

E E → T E’ error error E → T E’ error error 

E’ error E’ → + T E’ error error E’ → ε E’ → ε 

T T → F T’ error error T → F T’ error error 

T’ error T’ → ε T’ → * F T’ error T’ → ε T’ → ε 

F F → id error error F → ( E ) error error 

Tabelle 3.2: Beispiel einer Parse-Tabelle. 

Nun betrachten wir das Nichtterminal E ′ : Für die Produktion E ′ → + T E ′ gilt: 

FIRST(+ T E ′ ) = {+}, also wird die Produktion im ersten Schritt in die entsprechende 

Spalte eingetragen. 

Aufgrund der Produktion E ′ → ε müssen wir die FOLLOW-Menge von E ′ nach 

Schritt (1b) des Verfahrens betrachten. Diese Menge sagt uns, ob der lookahead mit 

dem zusammenpaßt, was auf E ′ folgen kann. Es gilt: FOLLOW(E ′ ) = {), $}, daher 

wird die Produktion E ′ → ε in die entsprechenden Spalten der Tabelle eingetragen. 

Die Produktionen T → F T ′ und T ′ → ∗ F T ′ | ε werden analog behandelt. Dabei ist 

zu beachten, daß FOLLOW(T ′ ) = {+, ), $}. 

Die Behandlung der Produktionen des Nichtterminals F verläuft analog. 

Wir können dieses Konstruktionsverfahren auch als LL(1)-Test verwenden: Wenn ein 

Feld der Parse-Tabelle im Laufe des Verfahrens mehr als einen Eintrag erhält, ist die 

Grammatik nicht LL(1). 

Nachdem wir für eine LL(1)-Grammatik die zugehörige Parse-Tabelle erzeugt haben, 

benötigen wir noch ein Verfahren, das die deterministische Top-Down-Analyse mit 

Hilfe der Parse-Tabelle durchführt. Die Eingabe sei mit dem Eingabeendezeichen $ 

abgeschlossen. Gleichzeitig verwenden wir dieses Zeichen auch als “unterstes” Symbol 

auf dem Keller, um einen leeren Keller anzuzeigen. Ein Parse-Verfahren für deterministische 

Top-Down-Analyse unter Verwendung dieser Konventionen ist im folgenden 

Algorithmus angegeben. 

Deterministische Top-Down-Analyse mit Parse-Tabelle. 

Eingabe: Parse-Tabelle M für Grammatik G und ein Eingabewort w 

Ausgabe: Linksableitung von w, falls w ∈ L(G), sonst Fehlermeldung 

Verfahren: 

Der Kellerautomat befinde sich in folgender Anfangskonfiguration: S$ liege auf 

dem Keller (Kellerspitze links), wobei S Startsymbol von G, w$ befinde sich 

im Eingabepuffer und der Eingabezeiger stehe auf dem ersten Symbol von w. 

Wir geben den Algorithmus in Form eines Pseudocode-Programms an: 

64

1 repeat 


2 s e i X oberstes Kellersymbol und a aktuelles 

Eingabesymbol 

3 if X Terminal then 

4 if X = a then 

5 entferne X vom Keller und r”ucke Eingabezeiger 

vor 

6 else error 

7 else (∗ X i s t Nichtterminal ∗) 

8 if M[X,a] = X → Y1Y2...Yk then begin 

9 entferne X vom Keller , lege Yk,Yk−1,...,Y1 auf den 

Keller 

10 (Y1 neue Kellerspitze ) , gib Produktion 

X → Y1Y2...Yk aus 

11 end 

12 else error 

13 until X = $ (∗ Keller l e e r ∗) 

65



Wir analysieren das Wort id + id mit Hilfe der in Tabelle 3.2 angegebenen Parse- 

Tabelle. 

Eingabe Keller Ausgabe 

id + id $ E $ 

id + id $ T E ′ $ E → TE ′ 

id + id $ F T ′ E ′ $ T → F T ′ 

id + id $ id T ′ E ′ $ F → id 

+ id $ T ′ E ′ $ ε 

+ id $ E ′ $ T ′ → ε 

+ id $ + T E ′ $ E ′ → + T E ′ 

id $ T E ′ $ ε 

id $ F T ′ E ′ $ T → F T ′ 

id $ id T ′ E ′ $ F → id 

$ T ′ E ′ $ ε 

$ E ′ $ T ′ → ε 

$ $ E ′ → ε 

$ $ accept 

Nach dieser Analyse eines korrekten Eingabeworts analysieren wir das Eingabewort 

id + * id, das mit der Grammatik nicht erzeugt werden kann. 


id + * id $ E $ 

id + * id $ T E ′ $ E → T E ′ 

id + * id $ F T ′ E ′ $ T → F T ′ 

id + * id $ id T ′ E ′ $ F → id 

+ * id $ T ′ E ′ $ ε 

+ * id $ E ′ $ T ′ → ε 

+ * id $ + T E ′ $ E ′ → + T E ′ 

* id $ T E ′ $ ε 

* id $ T E ′ $ error 

Behandlung von mehrdeutigen Grammatiken 

Wir haben bereits gezeigt, daß mehrdeutige Grammatiken nicht die LL(k)-Eigenschaft 

besitzen und daher Eingaben mit ihnen nicht deterministisch analysierbar sind (siehe 

Satz 7). Als Beispiel für eine mehrdeutige Grammatik haben wir in Beispiel 18 

das dangling-else-Problem betrachtet. Obwohl die Grammatik für die if-then-else- 

Anweisung nicht LL(k) ist, wird sie in Übersetzern (z.B. für Pascal) verwendet. Wie 

kann man also eine mehrdeutige Grammatik parsen? 

66


a b e i t $ 

S S → a S → iEtSS ′ 

S ′ S ′ → ε, S ′ → eS S ′ → ε 

E E → b 

Tabelle 3.3: Parse-Tabelle für dangling-else-Grammatik. 

Wir betrachten die linksfaktorisierte Grammatik für das dangling else aus Beispiel 

26, 

S → i E t S S’ | a 

S’ → e S | ε 

E → b, 

und konstruieren für diese Grammatik die zugehörige Parse-Tabelle M. 

Bei dieser Konstruktion ensteht ein doppelter Eintrag im Feld M[S ′ ,e]. Also ist 

die Grammatik nicht LL(1). Als pragmatische Lösung bietet sich an, die Produktion 

S ′ → ε aus dem Feld M[S ′ ,e] zu löschen, so daß gilt M[S ′ ,e] = {S ′ → eS}. 

Dies entspricht der üblichen Konvention, das else dem unmittelbar vorangehenden 

then zuzuordnen. Wenn wir uns in der innersten Schachtelung mehrerer if-then- 

Anweisungen befinden, und es steht ein else im lookahead, so soll dieses else dem 

innersten if zugeordnet werden. 

In diesem Beispiel ist durch geschickte Manipulation der Parse-Tabelle die deterministische 

Top-Down-Analyse ermöglicht worden. Es gibt aber keine allgemeine Regel 

für solche “Tricks”. 

3.3.3 Erweiterte kontextfreie Grammatiken 

Im vorherigen Abschnitt haben wir gesehen, daß linksrekursive Grammatiken nicht 

die LL(k)-Eigenschaft besitzen (siehe Satz 8). Bei der Beschreibung von Programmiersprachen 

treten linksrekursive Grammatiken aber relativ häufig auf, da sich mit 

ihnen “Auflistungen” sehr einfach beschreiben lassen (z.B. id+id+id in arithmetischen 

Ausdrücken, Anweisungsfolgen usw.). Aus diesem Grund möchte man eine 

Lösung finden, die die einfache Beschreibung von Auflistungen erlaubt und trotzdem 

das deterministische Parsen ermöglicht. Diese Möglichkeit bieten die erweiterten 

kontextfreien Grammatiken. Sie beruhen auf folgender Idee: Da sich Auflistungen 

mit regulären Ausdrücken beschreiben lassen (durch den ∗ -Operator), lassen wir nun 

reguläre Ausdrücke auf der rechten Seite von Produktionen zu. 

Definition 28 

Eine erweiterte kontextfreie Grammatik ist ein Tupel G = (VN,VT,ρ,S), wobei VN, 

VT und S wie üblich definiert sind und ρ : VN → reg(VN ∪ VT) eine Abbildung der 

67


Nichtterminale in die Menge der regulären Ausdrücke über VN ∪ VT ist. 

Es ist möglich, ρ als Abbildung zu definieren, da verschiedene Alternativen für ein 

Nichtterminal mit Hilfe des Alternativoperators | in einem regulären Ausdruck zusammengefaßt 

werden können. 

Beispiel 29 

Betrachten wir die Grammatik S → a |b. Handelt es sich bei der Grammatik um eine 

“normale” kontextfreie Grammatik, besitzt das Nichtterminal S zwei Produktionen 

S → a und S → b, wobei das | als Trennsymbol zwischen den beiden Produktionen 

verwendet wird. Interpretieren wir die Grammatik als erweiterte kontextfreie Grammatik, 

besitzt S nur eine Produktion S → a | b, die den regulären Auswahloperator | 

enthält. 

Beispiel 30 (Arithmetische Ausdrücke) 

Wir geben eine erweiterte kontextfreie Grammatik für die Sprache der arithmetischen 

Audrücke aus Beispiel 24 an. Dabei ergänzen wir die Menge der Operatoren um − 

und /. 

S → E 

E → T {{ + | − } T } ∗ 

T → F {{ ∗ | / } F } ∗ 

F → ( E ) | id 

Hier verwenden wir die Zeichen { und } zur Klammerung der regulären Ausdrücke 

in den rechten Regelseiten der Grammatik. Die Linksrekursion der Grammatik aus 

Beispiel 24 wurde durch den regulären ∗ -Operator ersetzt. Ein Ausdruck (Nichtterminal 

E) besteht aus einem Term (Nichterminal T), dem beliebig viele (also auch 

keine) Terme, getrennt durch einen der Operatoren + oder −, folgen können. Die 

Auswahl zwischen + und − wird durch den regulären Auswahloperator | dargestellt. 

Analog zu Ableitungen für kontextfreie Grammatiken definieren wir Ableitungen für 

erweiterte kontextfreie Grammatiken. 

Definition 29 

Sei G = (VN,VT,ρ,S) erweiterte kontextfreie Grammatik. 

Die Relation ⇒ R l ⊆ reg(VN ∪VT)×reg(VN ∪VT) (“leitet regulär links ab”) ist definiert 

durch 

68 

1. wXβ ⇒ R l wαβ für α = ρ(X), 

2. w(r1|...|rn)β ⇒ R l wriβ für 1 ≤ i ≤ n, 

3. w(r) ∗ β ⇒ R l wβ, 

w(r) ∗ β ⇒ R l wr(r) ∗ β.

S ⇒R l E 

⇒R l T {{+ | −}T } ∗ 

⇒R l F {{∗ | /}F } ∗ {{+ | −}T } ∗ 

⇒R l { ( E ) | id } {{∗ | /}F } ∗ {{+ | −}T } ∗ 

⇒R l id {{∗ | /}F } ∗ {{+ | −}T } ∗ 

⇒R l id {{+ | −}T } ∗ 

⇒R l id {+ | −}T {{+ | −}T } ∗ 

⇒R l id + T {{+ | −}T } ∗ 

⇒R l id + F {{∗ | /}F } ∗ {{+ | −}T } ∗ 

⇒R l id + { ( E ) | id } {{∗ | /}F } ∗ {{+ | −}T } ∗ 

⇒R l id + id {{∗ | /}F } ∗ {{+ | −}T } ∗ 

⇒R l id + id {∗ | /}F {{∗ | /}F } ∗ {{+ | −}T } ∗ 

⇒R l id + id ∗ F {{∗ | /}F } ∗ {{+ | −}T } ∗ 

⇒R l id + id ∗ { ( E ) | id } {{∗ | /}F } ∗ {{+ | −}T } ∗ 

⇒R l id + id ∗ id {{∗ | /}F } ∗ {{+ | −}T } ∗ 

⇒R l id + id ∗ id {{+ | −}T } ∗ 

id + id ∗ id 

⇒ R l 

Abbildung 3.11: Beispiel einer regulären Ableitung. 


⇒R∗ l sei die reflexive und transitive Hülle von ⇒R l . Die von G definierte Sprache ist 

dann L(G) = {w ∈ V ∗ 

T | S ⇒R∗ l w}. 


In Abbildung 3.11 ist die Ableitung des Satzes id+id∗id der Grammatik aus Beispiel 

30 angegeben. 

Für erweiterte kontextfreie Grammatiken gibt es analog die Klasse der erweiterten 

LL(k)-Grammatiken (kurz ELL(k)). Zur Berechnung der FIRST- und FOLLOW- 

Mengen der Symbole erweiterter kontextfreier Grammatiken kann das folgende Verfahren 

verwendet werden. Zuvor führen wir den Begriff der k-Konkatenation ein, der 

im Konstruktionsverfahren verwendet wird. 

Definition 30 

Die Abbildung ⊕k : V ∗ 

T × V ∗ 

T → V ≤k 

T , definiert durch u ⊕k v = k : uv heißt die k- 

Konkatenation. 

Analog läßt sich ⊕k auf Mengen von Wörtern definieren. Seien L,M Mengen von 

Wörtern. Dann ist L ⊕k M = {u ⊕k v | u ∈ L,v ∈ M}. 

Die k-Konkatenation von u und v berechnet den k-Präfix der Konkatenation von u 

und v. 

69


Konstruktion der FIRST- und FOLLOW-Mengen für eine ELL(1)-Grammatik. 

Die FIRST- und FOLLOW-Mengen für eine ELL(1)-Grammatik 

G = (VN,VT,P,S) werden wie folgt berechnet: 

• Sei X ∈ VN. FIRST(X) ist definiert durch: 

– Falls X → r ∈ P, wobei r regulärer Ausdruck über VN ∪ VT, dann 

FIRST(X) = FIRST(r). 

• Sei r regulärer Ausdruck über VN ∪VT. FIRST(r) ist induktiv definiert durch: 

– Falls r = ε, dann FIRST(r) = ε, 

– falls r = a mit a ∈ VT, dann FIRST(r) = {a}, 

– falls r = r1 | r2, dann FIRST(r) = FIRST(r1) ∪ FIRST(r2), 

– falls r = r1r2, dann FIRST(r) = FIRST(r1) ⊕1 FIRST(r2), 

– falls r = (r1), dann FIRST(r) = FIRST(r1), 

– falls r = r ∗ 1, dann FIRST(r) = {ε} ∪ FIRST(r1). 

• Sei X ∈ VN. Als Hilfskonstrukt verwenden wir Fol(X,r), die Menge der Terminalwörter 

der Länge ≤ 1, die in einer erweiterten Satzform r – einem regulären 

Ausdruck über VN ∪ VT – direkt auf X folgen können. 

– Fol(X,ε) = ∅, 

– Fol(X,r) = ∅, falls X in r nicht vorkommt, 

– Fol(X,X) = {ε}, 

– Fol(X,r1r2) = (Fol(X,r1) ⊕1 FIRST(r2)) ∪ Fol(X,r2), 

– Fol(X,r1|r2) = Fol(X,r1) ∪ Fol(X,r2), 

– Fol(X, (r)) = Fol(X,r), 

– Fol(X,r ∗ ) = Fol(X,r) ⊕1 FIRST(r ∗ ). 

• Nun definieren wir für X ∈ VN die Mengen FOLLOW(X) als die kleinsten 

Mengen mit: 

– Falls X = S, dann ε ∈ FOLLOW(X), 

– falls X → r ∈ P, dann Fol(Y,r) ⊆ FOLLOW(Y ) für alle Y ∈ VN, 

– falls X → r ∈ P und für ein Y gilt ε ∈ Fol(Y,r), 

dann FOLLOW(X) ⊆ FOLLOW(Y ). 

Bei den Definitionen ist zu beachten, daß ∅ ⊕1 M = ∅ für alle Mengen M. 

Übergangsgraphen für erweiterte kontextfreie Grammatiken 

Da in erweiterten kontextfreien Grammatiken die rechten Regelseiten reguläre Ausdrücke 

enthalten dürfen, stellen wir diese rechten Regelseiten analog zu Kapitel 2 als 

Übergangsgraphen dar. Diese können, wie in Kapitel 2 beschrieben, aus den regulären 

70

S: 

E: 

T: 

F: 

E 

T 

F 

ε 

ε 

T 

+ 

F 

( E ) 

id 

- 

* 

/ 


Abbildung 3.12: Übergangsgraphen für arithmetische Ausdrücke. 

Ausdrücken generiert werden. 


In Abbildung 3.12 sind Übergangsgraphen für die rechten Regelseiten der erweiterten 

kontextfreien Grammatik aus Beispiel 30 zur Beschreibung der arithmetischen 

Ausdrücke angegeben. 

Wie in Abbildung 3.12 zu sehen ist, können Kanten der Übergangsgraphen auch mit 

Nichtterminalsymbolen beschriftet sein. Da jedem Nichtterminalsymbol ein eigener 

Übergangsgraph zugeordnet ist, stellt eine solche Kante eine Art von “Prozeduraufruf” 

des Graphen dar, der dem entsprechenden Nichtterminal zugeordnet ist. Auf 

diese Weise erhalten wir “rekursive endliche Automaten” (mit direkter oder indirekter 

Rekursion). Diese Übergangsgraphen entsprechen genau den üblichen Syntaxdiagrammen 

für Programmiersprachen. 

Syntaxdiagramme bilden die Basis für eine besonders einfache Implementierung von 

Parsern für LL(k)-Sprachen (insbesondere LL(1)) mit Hilfe von Programmiersprachen, 

die Rekursion erlauben. Diese Parser werden recursive descent-Parser genannt. 

Top-Down-Parsen durch “rekursiven Abstieg” 

Bisher haben wir Parse-Verfahren für LL(1)-Grammatiken mit Hilfe einer Datenstruktur 

“Keller” durch einen iterativen Algorithmus implementiert. Dieser verwen- 

71


det eine Parse-Tabelle, die Informationen über die nächste anzuwendende Produktion 

unter Berücksichtigung des lookaheads enthält. 

Nun betrachten wir das Verfahren der Top-Down-Analyse durch rekursiven Abstieg 

(recursive descent), welches die besonders einfache Implementierung eines LL(1)- 

Parsers erlaubt. Wir verwenden als Grundlage dieses Verfahrens die oben erwähnten 

Syntaxdiagramme und erzeugen, analog zum Scanner, daraus ein Programm, welches 

jetzt aber rekursive Aufrufe enthält, da die Syntaxdiagramme ebenfalls Rekursion 

beinhalten. 

Für jedes Nichtterminal wird eine Prozedur nach folgendem Schema erzeugt: 

Beginne mit dem Anfangsknoten des Graphen. Betrachte die Ausgangskanten und 

vergleiche das aktuelle Symbol im lookahead mit den FIRST-Mengen ihrer Beschriftungen. 

Eine ε-Kante wird nur dann benutzt, wenn das lookahead-Symbol in keiner 

dieser Mengen enthalten ist (in diesem Fall wird der lookahead mit den FOLLOW- 

Mengen der Beschriftungen verglichen). Wir unterscheiden die folgenden Fälle: 

• Falls die Kante mit einem Terminalsymbol beschriftet ist, das mit dem lookahead 

übereinstimmt, gehe zum Folgeknoten über (die Konstruktoren in den 

regulären Ausdrücken werden in Kontrollstrukturen wie sequentielle Komposition, 

if-, while-, repeat- und case-Anweisungen übersetzt) und fordere das 

nächste Symbol des Quellprogramms an. 

• Falls die Kante mit einem Nichtterminalsymbol beschriftet ist, rufe die entsprechende 

Prozedur auf. 

• Falls keine Kante anwendbar ist (auch keine ε-Kante), liegt ein Syntaxfehler 

vor. 

Das Programm beginnt die Syntaxanalyse durch den Aufruf der Prozedur für das 

Startsymbol. 

Beispiel 33 

Wir betrachten die Grammatik G zur Beschreibung einer Untermenge der Pascal- 

Typen mit den folgenden Produktionen: 

type → simple 

| ↑ id 

| array [ simple ] of type 

simple → integer 

| char 

| num dotdot num 

Für die Zeichenfolge “..” verwenden wir das Symbol dotdot, da diese Zeichenfolge 

als Einheit behandelt wird (wie “:=”) und somit schon vom Scanner als ein Symbol 

geliefert wird. 

Wir können G als “normale” oder als besonders einfache erweiterte kontextfreie 

Grammatik betrachten. 

72

type: 

simple: 

simple 

array [ simple ] of type 

integer 

char 

num dotdot num 

Abbildung 3.13: Übergangsgraphen für Pascal-Typen. 


Die Syntaxdiagramme für G sind in Abbildung 3.13 dargestellt. 

Die Berechnung der FIRST-Mengen der Nichtterminalsymbole ergibt 

FIRST(simple) = {integer,char,num} und 

FIRST(type) = FIRST(simple) ∪ {↑,array} = 

{integer,char,num, ↑,array}. 

Es treten keine ε-Kanten auf, also müssen die FOLLOW-Mengen nicht berücksichtigt 

werden. Anhand der Syntaxdiagramme können wir nun einen recursive descent- 

Parser implementieren (siehe Abbildung 3.14). 

Die Hilfsprozedur match prüft, ob ein Symbol mit dem aktuellen lookahead übereinstimmt. 

Ist dies der Fall, wird das nächste Symbol vom Scanner angefordert (durch 

den Aufruf von nexttoken) und in den lookahead geladen, andernfalls ist eine Fehlersituation 

eingetreten. In den Prozeduren type und simple wird die Auswahl zwischen 

den Ausgangskanten eines Knotens durch verschachtelte if-then-else-Anweisungen 

dargestellt. Als Bedingung wird dabei ein Vergleich des lookaheads mit der FIRST- 

Menge der jeweiligen Kantenbeschriftung verwendet. Ein Schritt, also die Verwendung 

einer Kante, wird durch die Prozedur match realisiert, indem sie zum einen 

überprüft, ob der aktuelle lookahead dem erwarteten Symbol entspricht, und zum anderen 

den aktuellen lookahead durch Anfordern des nächsten Symbols “verbraucht”. 

In Abbildung 3.15 ist der Aufrufgraph der Prozeduren des Parsers für die Analyse des 

Satzes array [ num dotdot num ] of integer angegeben. Die Aufrufe der Prozedur 

match bilden die Blätter des Aufrufgraphen, die der Prozeduren type und simple die 

inneren Knoten. Da jeder Aufruf von match der Überprüfung eines Terminalssymbols 

dient und der Aufruf von type und simple einem Nichtterminalsymbol entspricht, wird 

durch den Aufrufgraph der Prozeduren der Strukturbaum der Analyse implizit erzeugt. 

id 

73


1 procedure type ; 

2 begin 

3 if lookahead i s in {integer, char, num} then 

4 simple 

5 else 

6 if lookahead = ′ ↑ ′ then begin 

7 match( ′ ↑ ′ ) ; match(id ) ; 

8 end 

9 else 

10 if lookahead = array then begin 

11 match(array) ; match ( ’ [ ’ ) ; simple ; 

12 match ( ’ ] ’ ) ; match( of ) ; type 

13 end 

14 else error 

15 end; 

16 

17 procedure simple ; 

18 begin 

19 if lookahead = integer then 

20 match( integer ) 

21 else 

22 if lookahead = char then 

23 match(char) 

24 else 

25 if lookahead = num then begin 

26 match(num) ; match(dotdot) ; match(num) 

27 end 

28 else error 

29 end; 

30 

31 procedure match ( t : token ) ; 

32 begin 

33 if lookahead = t then 

34 lookahead := nexttoken 

35 else error 

36 end }; 

74 

Abbildung 3.14: Beispiel eines recursive descent-Parsers.

type 

match( array) match( ’[’) simple match( ’]’) match( of ) type 

match( num ) match( dotdot ) match( num ) simple 


match( integer) 

Abbildung 3.15: Aufrufgraph einer recursive descent-Syntaxanalyse. 

Der recursive descent-Parser kommt ohne einen durch eine Datenstruktur explizit 

definierten Keller aus, da diese Aufgabe implizit vom Laufzeitsystem der Sprache, in 

der wir unseren Parser implementiert haben, übernommen wird. 

3.3.4 Fehlerbehandlung bei der Top-Down-Analyse 

Wir beschreiben zunächst die Fehlerbehandlung bei Parsern im allgemeinen. Die 

Fehlerbehandlung eines Parsers muß folgenden Kriterien genügen: 

• Fehler müssen zuverlässig festgestellt und durch verständliche Fehlermeldungen 

dem Benutzer mitgeteilt werden. 

• Nach einem gefundenen Fehler soll die Analyse des Quelltexts fortgeführt werden, 

um weitere Fehler im Programmtext entdecken zu können. Daher soll der 

Parser in einer Fehlersituation möglichst schnell wieder “aufsetzen”, d.h. mit 

der Analyse fortfahren. Dabei sollen sogenannte “Scheinfehler”, d.h. durch die 

Behandlung des ersten Fehlers verursachte Folgefehler, vermieden werden. 

• Die Fehlerbehandlung darf die schnelle Übersetzung korrekter Programme nicht 

behindern. 

Zu den Syntaxfehlern gehören 

• Zeichensetzungsfehler: zuviele oder zuwenige ’;’, ’;’ statt ’,’, usw., 

• Operatorenfehler: z.B. ’=’ statt ’:=’, 

• Schlüsselwortfehler: fehlende oder falsch geschriebene Schlüsselwörter, 

• Fehler in der Klammerstruktur 

• ... 

Das Wiederaufsetzen (recovery) eines Parsers soll möglichst früh geschehen, d.h. es 

sollen möglichst wenige Symbole überlesen werden. Neben dem Wiederaufsetzen ist 

es durch heuristische Verfahren möglich, durch lokale Korrekturen, die der Parser 

vornimmt, die Analyse fortzusetzen. 

75


Wir betrachten verschiedene recovery-Strategien: 

Panic recovery: Die Idee bei dieser Strategie besteht darin, einen Teil der Eingabe 

nach Auftreten eines Fehlers zu überlesen und dann mit der Analyse fortzufahren. 

Das Ende des zu überlesenden Abschnitts der Eingabe wird durch synchronisierende 

Symbole angegeben. Synchronisierende Symbole sind z.B. die 

Symbole, die Anweisungen abschließen (etwa ’;’ oder end). Tritt während der 

Analyse einer Anweisung ein Fehler auf, wird der restliche Text der Anweisung 

überlesen (also alle Symbole bis zum nächsten synchronisierenden Symbol) und 

die Analyse mit der nächsten Anweisung fortgesetzt. Der Nachteil dieser Methode 

besteht darin, daß eventuell relativ große Teile der Eingabe überlesen 

werden (und daher Fehler, die in diesen Abschnitten existieren, in der aktuellen 

Analyse nicht gefunden werden). Andererseits ist dieses Verfahren sicher, 

da die Eingabe stets verkürzt wird und das Verfahren daher terminiert. 

Konstrukt-orientierte recovery: Bei diesem Verfahren ist der Parser in der Lage, 

lokale Korrekturen im Quelltext beim Auftreten eines Fehlers vorzunehmen. 

Der Parser kann das Präfix der Eingabe durch eine modifizierte Symbolfolge 

ersetzen, so daß eine Fortsetzung der Analyse möglich ist. Zum Beispiel kann ein 

Parser, der bei der Analyse einer Zuweisung bemerkt, daß statt des Symbols ’:=’ 

das Symbol ’=’ verwendet wurde, das ’=’ durch das ’:=’ ersetzen. Nachteilig ist 

bei dieser Strategie, daß die Gefahr von Endlos-Schleifen besteht, z.B. wenn der 

Parser immer wieder Symbole vor dem aktuellen Eingabesymbol einsetzt. Eine 

zusätzliche Schwierigkeit entsteht, wenn der Fehler tatsächlich früher auftritt, 

als er vom Parser bemerkt wird (z.B. wird ein fehlendes begin in Pascal erst 

bei der Analyse der folgenden Anweisung bemerkt). In diesem Fall nimmt der 

Parser die Korrekturversuche an der falschen Stelle innerhalb des Quelltextes 

vor. 

Fehlerproduktionen: Für die Behandlung von “Standard-Fehlern”, die in Programmiersprachen 

häufig auftreten, ist es manchmal hilfreich, die kontextfreie Grammatik 

um Produktionen für diese fehlerhaften Konstrukte zu erweitern. Tritt 

ein solcher Standard-Fehler auf, wird durch die Anwendung der zugehörigen 

Fehler-Produktion eine Behandlung des Fehlers vorgenommen. 

Globale Korrekturen: Diese Verfahren wenden spezielle Algorithmen an, die minimale 

Folgen von Änderungen finden, um die fehlerhafte Eingabe in eine korrekte 

Eingabe zu transformieren. Hierzu stehen Änderungsoperationen wie Einfügen, 

Löschen und Ändern von Symbolen zur Verfügung. Diese Verfahren sind im 

allgemeinen zu aufwendig und werden daher nur eingeschränkt in Parsern verwendet, 

z.B. für das Finden der Ersetzungsstrings bei der konstrukt-orientierten 

Fehlerbehandlung. 

76


id + * ( ) $ 

E E → T E’ E → T E’ synch synch 

E’ E’ → + T E’ E’ → ε E’ → ε 

T T → F T’ synch T → F T’ synch synch 

T’ T’ → ε T’ → * F T’ T’ → ε T’ → ε 

F F → id synch synch F → ( E ) synch synch 

Tabelle 3.4: Für Fehlerbehandlung modifizierte Parse-Tabelle. 

Recovery in Top-Down-Parsern 

LL(k)-Parser haben die Eigenschaft, Fehler im Quellprogramm zum frühestmöglichen 

Zeitpunkt zu entdecken. Fehler werden in dem Moment erkannt, in dem das bisher 

gelesene Präfix der Eingabe kein gültiges Wort sein kann (viable prefix-Eigenschaft). 

Ein Top-Down-Parser hat einen Fehler erkannt, wenn 

• das oberste Symbol des Kellers ein Terminalsymbol ungleich dem aktuellen 

lookahead ist, 

• oder wenn das oberste Symbol des Kellers ein Nichtterminal A ist, das Terminalsymbol 

a den aktuellen lookahead bildet und in der Parse-Tabelle M der 

Eintrag M[A,a] leer ist bzw. error enthält. 

Für die Strategie der panic recovery werden synchronisierende Symbole benötigt. 

Folgende Symbole eignen sich als synchronisierende Symbole: 

1. Für ein Nichtterminal A: 

• FOLLOW(A): der Parser überliest die Eingabe, bis er ein Element aus 

FOLLOW(A) findet. Außerdem wird A vom Keller entfernt (es wird dem 

Parser die korrekte Analyse des zu A gehörenden Abschnitts der Eingabe 

vorgetäuscht). 

• Symbole, die Konstrukte abschließen, etwa Anfangssymbole von höher stehenden 

Konstrukten (z.B. Schlüsselwörter, mit denen Anweisungen beginnen). 

Zum Beispiel werden in C Anweisungen durch ’;’ abgeschlossen. 

Fehlt im Quelltext ein ’;’, würde sonst der Beginn der nächsten Anweisung 

überlesen, da er nicht in der FOLLOW-Menge enthalten ist. 

• FIRST(A): hierdurch wird ein neuer Parse-Versuch für A möglich, falls 

beim Überlesen ein Symbol aus FIRST(A) gefunden wird. 

2. Für Terminale werden alle anderen Terminalsymbole als synchronisierende Symbole 

verwendet. Wenn das Terminalsymbol auf dem Keller nicht zum aktuellen 

lookahead paßt, wird es vom Keller entfernt und der Parser gibt eine Meldung 

aus, daß das Terminal in den Quelltext “eingefügt” wurde. 

Eine weitere Möglichkeit besteht darin, für Nichtterminale A mit Produktion A → ε 

77


78 


id * + id $ E $ 

id * + id $ T E’ $ E → T E ′ 

id * + id $ F T’ E’ $ T → F T ′ 

id * + id $ id T’ E’ $ F → id 

* + id $ T’ E’ $ ε 

* + id $ * F T’ E’ $ T ′ → ∗ F T ′ 

+ id $ F T’ E’ $ ε 

+ id $ T’ E’ $ error, F wird entfernt, 

da Eintrag synch 

+ id $ E’ $ T ′ → ε 

+ id $ + T E’ $ E ′ → + T E ′ 

id $ T E’ $ ε 

id $ F T’ E’ $ T → F T ′ 

id $ id T’ E’ $ F → id 

$ T’ E’ $ ε 

$ E’ $ T ′ → ε 

$ $ E ′ → ε 

$ $ accept 

Tabelle 3.5: Beispiel einer Ableitung mit Fehlerbehandlung.


diese Produktion als “default” zu verwenden, d.h. wenn keine andere Produktion 

zum aktuellen lookahead paßt (dies verzögert eventuell die Fehlererkennung). 

Beispiel 34 

Wir modifizieren die Parse-Tabelle aus Tabelle 3.2 auf Seite 64, indem wir die error- 

Einträge aus der Tabelle entfernen. Als synchronisierende Symbole verwenden wir die 

FOLLOW-Mengen der Nichtterminale: 

FOLLOW(E) = {), $}, FOLLOW(T) = {+, ), $}, 

FOLLOW(F) = {+, ∗, ), $}. 

In die Felder der Parse-Tabelle tragen wir in den Spalten, die mit den Symbolen 

aus der jeweiligen FOLLOW-Menge beschriftet sind, die Anweisung synch ein. Die 

übrigen Felder, die zuvor mit error beschriftet waren, lassen wir leer (Tabelle 3.4). 

Wir interpretieren die Parse-Tabelle wie folgt: 

• bei einem leeren Eintrag wird das aktuelle Eingabesymbol vom Parser überlesen, 

• bei einem Eintrag synch wird das Nichtterminal an der Kellerspitze vom Keller 

entfernt. 

Zusätzlich wird, falls das oberste Kellerelement ein Terminalsymbol ungleich dem 

lookahead ist, dieses Symbol vom Keller entfernt. 

Wir analysieren mit Hilfe der modifizierten Parse-Tabelle das Eingabewort id * + 

id (siehe Tabelle 3.5). 

Die fehlerhafte Eingabe wird durch die Fehlerbehandlung erfolgreich analysiert. Beim 

Erreichen des Fehlers wird eine Fehlermeldung ausgegeben und die Analyse durch das 

Löschen des Nichtterminals F vom Keller fortgesetzt. 

79


3.4 Bottom-Up-Syntaxanalyse 

Bei der Bottom-Up-Syntaxanalyse wird die Konstruktion des Strukturbaums einer 

Ableitung bei der Eingabe, also mit den Blättern des Baums, begonnen. Während 

der Analyse wird versucht, immer größere Abschnitte der Eingabe zu Nichtterminalen 

zusammenzufassen, bis am Ende der Analyse die gesamte Eingabe auf das Startsymbol 

der Grammatik reduziert wurde. Bei der Bottom-Up-Syntaxanalyse wird also 

der Strukturbaum von den Blättern zur Wurzel hin aufgebaut, während er bei der 

Top-Down-Analyse von der Wurzel ausgehend hin zu den Blättern konstruiert wird. 

Im Gegensatz zur Top-Down-Analyse, wo in jedem Schritt nur das oberste Symbol des 

Kellers verwendet werden konnte, erlauben wir bei der Bottom-Up-Syntaxanalyse zur 

Vereinfachung, daß auch mehrere Zeichen an der Kellerspitze gelesen werden können 

(für ein festes k ≥ 0). Dies ändert die Mächtigkeit des Modells der Kellerautomaten 

nicht, da das Lesen mehrerer Zeichen durch einen üblichen Kellerautomaten, der 

nur auf das oberste Kellersymbol zugreifen kann, simuliert werden kann (etwa unter 

Zuhilfenahme von k ∗ |Γ| Zuständen). 

Zur Erinnerung: für ein Alphabet Σ sei Σ≤k = � 

0≤i≤k Σi die Menge der Wörter mit 

maximaler Länge k einschließlich ε. 

Wie bei der Top-Down-Analyse beschreiben wir zunächst die allgemeine Bottom-Up- 

Analyse (auch Shift-Reduce-Verfahren genannt), bevor wir die Verfahren zur Realisierung 

der deterministischen Bottom-Up-Analyse einführen. 

Definition 31 

Der (nichtdeterministische) Bottom-Up-Analyseautomat für eine kontextfreie Grammatik 

G = (VN,VT,P,S) ist ein Kellerautomat mit 

• Eingabealphabet VT, 

• Kelleralphabet Γ = VN ∪ VT ∪ {$}, 

• Kellerstartsymbol $, 

• Ausgabealphabet {1,...,p} und der 

• Übergangsrelation ∆ ⊆ ((VT ∪ {ε}) × Γ ≤k ) × (Γ ≤1 × {1,...,p} ≤1 ), wobei 

((ε, ← α), (A,i)) ∈ ∆ :⇔ π(i) = A → α (Reduktionsschritt), 

((a,ε), (a,ε)) ∈ ∆ für a ∈ VT (Shift-Schritt) und 

((ε,S$), (ε,ε)) ∈ ∆ (Erkennungsende). 

Die Übergangsrelation enthält drei Arten von Regeln: 

80 

1. Die Regeln der Form ((ε, ← α), (A,i)) beschreiben einen Reduktionsschritt. Befindet 

sich die rechte Seite der i-ten Produktion A → α in umgekehrter Reihenfolge 

auf dem Keller ( ← α ist das zu α reverse Wort, auch handle genannt), wird die 

rechte Seite entfernt und durch das Nichtterminal A der Produktion ersetzt. 

Dabei wird die Nummer i der Produktion auf das Ausgabeband geschrieben


und die Eingabe bleibt unverändert. Da die rechte Seite einer Produktion auf 

dem Keller zu einem Nichtterminalsymbol reduziert wird, wird die Anwendung 

der Regel als Reduktionsschritt bezeichnet. 

2. Für jedes Terminalsymbol der Grammatik wird eine Regel der Form ((a,ε), (a,ε)) 

in die Übergangsrelation aufgenommen. Das aktuelle Symbol a der Eingabe 

wird aus der Eingabe entfernt und auf den Keller gelegt (das Symbol wird aus 

der Eingabe auf den Keller “geschoben”, daher wird die Anwendung eines solchen 

Übergangs als Shift-Schritt bezeichnet). Der Inhalt des Ausgabebandes 

wird nicht verändert. 

3. Die Regel((ε,S$), (ε,ε)) definiert das Erkennungsende der Analyse. Ist die Eingabe 

leer, d.h. alle Symbole der Eingabe wurden gelesen, und befinden sich auf 

dem Keller nur das Startsymbol der Grammatik und das Kellerstartsymbol $, 

ist die Analyse beendet und der Kellerautomat hat das Eingabewort akzeptiert. 

Durch die Übergangsrelation wird die Arbeitsweise des Bottom-Up-Parsers definiert. 

Die Eingabe wird symbolweise auf den Keller “geschoben”. Sobald auf dem Keller eine 

rechte Seite einer Produktion der Grammatik in umgekehrter Reihenfolge vorliegt, 

kann diese rechte Regelseite vom Keller entfernt und durch das Nichtterminalsymbol 

der linken Seite der Produktion ersetzt werden. Auf diese Weise werden immer größere 

Anfangsstücke der Eingabe auf den Keller gelegt und durch Reduktionsschritte in 

Nichtterminale umgewandelt. Die Analyse ist beendet, wenn die gesamte Eingabe 

gelesen, auf den Keller geschoben und zum Startsymbol der Grammatik reduziert 

werden konnte. 

Beispiel 35 (Bottom-Up-Analyse arithmetischer Ausdrücke) 

Wir betrachten wieder die Grammatik aus Beispiel 19 auf Seite 49: 

E → E A E (1) 

| ( E ) (2) 

| - E (3) 

| id (4) 

A → + (5) 

| - (6) 

| * (7) 

| / (8) 

| ↑ (9) 

Analog zu Beispiel 19 analysieren wir die Eingabe -(id+id). Die Bottom-Up-Analyse 

ist in Tabelle 3.6 angegeben. 

Die bei der Analyse entstandene Ausgabe ist eine Rechtsanalyse, d.h. sie stellt eine 

Rechtsableitung in umgekehrter Reihenfolge dar: 

E 3 ⇒ - E 2 ⇒ - ( E ) 1 ⇒ - ( E A E ) 4 ⇒ - ( E A id ) 5 ⇒ - ( E + id ) 

81


4 

E 

5 

- ( id - ( id 

E A E 

- ( id + id 

1 

3 

E 

E A E 

- ( id + id 

- 

E 

E 

E 

E A E 

E A 

- ( id + 

2 

( id + id ) 

4 

E 

E 

E A E 

- ( id + id ) 

Abbildung 3.16: Erzeugung eines Strukturbaums für einen arithmetischen Ausdruck. 

82

Eingabe Kellerinhalt Ausgabe 

- ( id + id ) $ 

( id + id ) - $ ε 

id + id ) ( - $ ε 

+ id ) id ( - $ ε 

+ id ) E ( - $ 4 

id ) + E ( - $ ε 

id ) A E ( - $ 5 

) id A E ( - $ ε 

) E A E ( - $ 4 

) E ( - $ 1 

ε ) E ( - $ ε 

ε E - $ 2 

ε E $ 3 

ε ε accept 


Tabelle 3.6: Beispielableitung eines Bottom-Up-Parsers. 

4 

⇒ - ( id + id ) 

In Abbildung 3.16 ist die Konstruktion des Strukturbaums gemäß den Analyseschritten 

der Tabelle dargestellt. Es entsteht derselbe Strukturbaum wie bei der Top-Down- 

Analyse in Abbildung 3.8, aber bei der Bottom-Up-Analyse wird der Strukturbaum 

“von unten nach oben” aufgebaut. 

Auch bei der allgemeinen Bottom-Up-Syntaxanalyse tritt Nichtdeterminismus auf. 

Wir betrachten die verschiedenen Situationen für Nichtdeterminismus: 

• Ein Shift-Schritt ist immer möglich, solange die Eingabe nicht leer ist. Wann 

soll eine Reduktion durchgeführt werden? 

• Das Erkennungsende ist unklar, falls das Startsymbol S in einer rechten Regelseite 

auftritt, z.B. in einer Grammatik mit den Produktionen S → A und 

A → S. Wenn auf dem Keller ein S steht, soll die Analyse beendet werden oder 

muß das S zu einem A reduziert werden? 

• Eventuell stehen mehrere Reduktionsmöglichkeiten zur Auswahl, z.B. bei den 

Produktionen A → α und B → α. Wenn auf dem Keller ← α steht, wird dann zu 

A oder zu B reduziert? Ein weiteres Problem entsteht z.B. für die Grammatik 

A → Bb |b. Wenn auf dem Keller die Symbole bB liegen (b Kellerspitze), soll 

dann nur das b oder bB zu A reduziert werden? 

Um eine deterministische Bottom-Up-Syntaxanalyse durchführen zu können, beschränken 

wir uns auf die Klasse der Sprachen, die mit einem lookahead von k 

83


Symbolen deterministisch zu erkennen sind. Diese Sprachen werden LR(k)-Sprachen 

genannt. 

3.4.1 LR(k)-Grammatiken 

Analog zu den LL(k)-Grammatiken bei der Top-Down-Analyse gibt es für die Bottom- 

Up-Analyse eine Klasse von kontextfreien Grammatiken, die die deterministische 

Analyse von Eingabewörtern erlauben. Diese Grammatiken heißen LR(k)-Grammatiken 

(das L steht für das Lesen der Eingabe von links nach rechts, das R steht für die 

Konstruktion einer Rechtsableitung). Wie die LL(k)-Grammatiken verwenden die 

LR(k)-Grammatiken einen lookahead von k Symbolen, um die Auswahl der nächsten 

Aktion deterministisch treffen zu können. 

Wir haben zuvor verschiedene Arten des Nichtdeterminismus betrachtet. Dabei haben 

wir gesehen, daß das Erkennungsende unklar ist, sobald das Startsymbol der 

Grammatik in rechten Regelseiten auftritt. Um diese Art von Nichtdeterminismus zu 

vermeiden, betrachten wir im folgenden nur Grammatiken, die startsepariert sind. 

Definition 32 

Eine kontextfreie Grammatik G = (VN,VT,P,S) heißt startsepariert, wenn S nur in 

einer Produktion S → A, A �= S, vorkommt. 

Wir können im folgenden voraussetzen, daß die Grammatiken startsepariert sind, 

denn zu einer Grammatik G läßt sich eine äquivalente startseparierte Grammatik G ′ 

wie folgt konstruieren: 

Sei S ′ Startsymbol von G ′ , und S ′ komme in G nicht vor. Die Produktionen von G ′ 

sind die Produktionen von G und die Produktion S ′ → S. Damit ist G ′ startsepariert. 

Auf diese Weise kann das Shift-Reduce-Verfahren für G ′ akzeptieren, wenn der 

Kellerinhalt S ′ und die Eingabe leer ist. 

Für mehrdeutige Grammatiken gibt es zu mindestens einem Satz mehr als eine 

Rechtsableitung. Also können wir in diesem Fall auch kein deterministisches Shift- 

Reduce-Verfahren erwarten. 

Nehmen wir also für die folgenden Überlegungen an, daß die betrachtete Grammatik 

eindeutig ist und daher jede Satzform genau eine Rechtsableitung besitzt. 

Definition 33 

Sei S ⇒ ∗ r βXu ⇒r βαu eine Rechtsableitung einer kontextfreien Grammatik G. α 

heißt dann der Griff der Rechtssatzform βαu. 

In einer nicht mehrdeutigen Grammatik ist der Griff einer Rechtssatzform das eindeutig 

bestimmte Teilwort, welches in einer Bottom-Up-Analyse im nächsten Reduktionsschritt 

durch ein Nichtterminal ersetzt werden muß, um zu einer Rechtsableitung 

zu gelangen. 

84


Sei S = α0 ⇒r α1 ⇒r ... ⇒r αm = w eine Rechtsableitung. Eine Grammatik G ist 

LR(k), wenn in jeder solchen Rechtsableitung und in jedem αi der Griff lokalisiert 

und die anzuwendende Produktion eindeutig bestimmt werden kann, indem man die 

αi von links bis höchstens k Symbole hinter dem Griff betrachtet. Wenn wir also die 

αi in αi = αβw aufteilen und es eine Produktion X → β gibt, dann ist der Schritt 

nach αi−1 = αXw eindeutig durch αβ und k : w bestimmt. Eine Grammatik G 

ist also genau dann LR(k), wenn der nächste anzuwendende Schritt aus der bisher 

gelesenen Eingabe (bis zum Ende des Griffs) und einem lookahead von k Symbolen 

nach dem Griff eindeutig zu bestimmen ist. 

Definition 34 

Sei G = (VN,VT,P,S) startseparierte kontextfreie Grammatik. G heißt LR(k)-Grammatik, 

wenn aus 

S 

⇒ ∗ r α X w ⇒r α β w 

⇒ ∗ r γ Y x ⇒r α β y 

und k : w = k : y folgt, daß α = γ und X = Y und x = y. 

Wenn k : w = k : y gilt, müssen also folgende Bedingungen erfüllt sein, damit G die 

LR(k)-Eigenschaft besitzt: 

• X = Y , d.h. das Nichtterminal, zu dem reduziert wird, muß eindeutig sein, 

• α = γ, d.h. der Griff befindet sich, von “vorne” gesehen, an derselben Position 

der Satzform, 

• x = y, d.h. der Griff befindet sich, von “hinten” gesehen, an derselben Position 

der Satzform. 

Durch die zweite und die dritte Bedingung ist die Zerlegung der Satzform eindeutig 

bestimmt. 

Beispiel 36 

1. Wir überprüfen, ob die Grammatik G mit den Produktionen 

S → a A c 

A → b A b | b 

die LR(1)-Eigenschaft besitzt. Dazu wenden wir Definition 34 an: 

S 

⇒ ∗ r 

α 

�� 

ab 

⇒ ∗ r abb 

�� 

γ 

X 

�� 

A 

A 

�� 

Y 

w 

�� 

bc ⇒r 

bbc 

�� 

x 

α 

�� 

ab 

⇒r ab 

�� 

α 

β 

�� 

b 

b 

�� 

β 

w 

�� 

bc 

bbbc 

�� 

y 

85


Es gilt 1 : w = 1 : y = b, aber α �= γ und x �= y. Also ist G keine LR(1)- 

Grammatik. Man kann zeigen, daß G für kein k eine LR(k)-Grammatik ist. 

2. Gegeben sei die Grammatik G ′ mit den folgenden Produktionen: 

S → a A c 

A → A b b | b 

Die Sprache L(G ′ ) = L(G) = {ab 2n+1 c | n ≥ 0} ist identisch mit der unter 

Punkt 1 erzeugten Sprache. Im Gegensatz zu G ist G ′ eine LR(0)-Grammatik. 

Wir betrachten die Rechtssatzformen, die während der Ableitung eines Wortes 

aus L(G ′ ) auftreten können: 

a) a A c 

b) a A b b b 2n c, n ≥ 0 

c) a b b 2n c, n ≥ 0 

In jedem dieser drei Fälle ist der Griff und die anzuwendende Produktion bereits 

durch den Präfix der Eingabe bis zum Ende des Griffs eindeutig bestimmt: 

a) trivial 

b) die Rechtssatzform läßt sich nur zu aAb 2n c in einer Rechtsableitung reduzieren 

(würden wir ein b zu einem A reduzieren, bekämen wir eine Rechtssatzform 

mit zwei A’s, die nicht weiter reduziert werden könnte, also ist 

der Griff Abb eindeutig). Dieser Fall ist durch das Präfix aAbb bestimmt. 

c) der Griff muß das erste b sein, da wir für weitere Ableitungsschritte das 

Nichtterminal A benötigen. Dieser Fall ist durch das Präfix ab bestimmt. 

Da die einzelnen Fälle durch das Präfix der Eingabe bis zum Ende des Griffs 

eindeutig bestimmt sind, ist kein weiterer lookahead notwendig. Also ist die 

Grammatik LR(0). 

3. Wir betrachten eine weitere Grammatik G ′′ , die dieselbe Sprache wie G und G ′ 

erzeugt: 

S → a A c 

A → b b A | b 

Wir betrachten, analog zu 2., die möglichen Rechtssatzformen der Ableitungen: 

a) a A c 

b) a b 2n b b A c, n ≥ 0 

c) a b 2n b c, n ≥ 0 

Der Fall a) ist trivial. Die in den Fällen b) und c) auftretenden Rechtssatzformen 

lassen sich zu ab k bα mit k ≥ 0 zusammenfassen. Falls α = c, ist der Griff 

das letzte Auftreten von b. Sonst ist der Griff bbA, der sich mit α überschneidet. 

Also ist die Entscheidung über die anzuwendende Produktion mit einem 

lookahead von 1 eindeutig zu bestimmen. Daher ist G ′′ eine LR(1)-Grammatik. 

An diesem Beispiel sehen wir, daß es für eine Sprache mehrere Grammatiken geben 

86

kann, die sich in bezug auf die LR(k)-Eigenschaft unterscheiden. 


Bevor wir detailliert auf das Konstruktionsverfahren für deterministische Bottom- 

Up-Parser eingehen, schildern wir kurz die Idee des Verfahrens. 

Idee für die Konstruktion des deterministischen Bottom-Up-Parsers für LR(k)- 

Grammatiken: LR(k)-Grammatiken besitzen die Eigenschaft, daß die Reduktion 

von αβw zu αAw durch αβ(k : w) vollständig bestimmt ist. Dies bedeutet, daß, 

wenn αβ auf dem Keller liegt und w in der Eingabe steht, man anhand von k : w 

entscheiden kann, ob ein Shift-Schritt oder ob und welcher Reduktionsschritt durchgeführt 

werden soll. Das Problem besteht darin, daß die Auswahl nicht nur vom 

Griff β, sondern auch dem weiteren Kellerinhalt, dem Präfix α, beeinflußt wird. Im 

allgemeinen gibt es jedoch unendlich viele mögliche Präfixe α. Daher ist es für die 

Konstruktion des Parsers notwendig, einen Weg zu finden, wie man die entsprechende 

Information endlich darstellen und in den Shift-Reduce-Algorithmus einbinden kann. 

Definition 35 

Sei S ⇒ ∗ r βXu ⇒r βαu eine Rechtsableitung zu einer kontextfreien Grammatik G. 

Dann heißt jedes Präfix von βα ein zuverlässiges Präfix von G. 

Ein zuverlässiges Präfix ist der Anfang einer Rechtssatzform, der sich nicht echt über 

den (bei einer nicht mehrdeutigen Grammatik eindeutigen) Griff hinaus erstreckt. 

In einem zuverlässigen Präfix ist also eine Reduktion höchstens am Ende möglich 

(sonst ist es bereits soweit wie möglich reduziert, da wir Rechtsableitungen betrachten). 

Zu einer Grammatik gibt es im allgemeinen unendlich viele zuverlässige Präfixe. 

Allerdings kann die Menge der zuverlässigen Präfixe endlich dargestellt werden. Wir 

zeigen im folgenden, daß die Menge der zuverlässigen Präfixe einer Grammatik durch 

einen endlichen Automaten darstellbar ist. Wir geben die Konstruktion dieses Automaten 

an und integrieren ihn in das Shift-Reduce-Verfahren. 

Definition 36 

Sei G kontextfreie Grammatik, A → αβ eine Produktion von G. Dann heißt das Tripel 

(A,α,β) ein (kontextfreies) Item (oder ein LR(0)-Element) von G. Wir schreiben das 

Item (A,α,β) als [A → α.β]. 

Ein Item der Form [A → α.] heißt vollständig. 

ItG bezeichnet die Menge der Items von G. 

vollstItG bezeichnet die Menge der vollständigen Items von G. 

Eine Produktion A → XY Z erzeugt die Items [A → .XY Z], [A → X.Y Z], [A → 

XY.Z] und [A → XY Z.] (nur letzteres ist vollständig). Die Produktion A → ε 

erzeugt das Item [A → .]. 

87


Items lassen sich wie folgt interpretieren: ein Item [A → α.β] repräsentiert einen 

Analysezustand, in dem beim Versuch, ein Wort für A zu erkennen, bereits ein Wort 

für α erkannt wurde. 

Die Menge der Items einer kontextfreien Grammatik ist endlich. 

Definition 37 

Ein Item [A → α.β] heißt gültig für ein zuverlässiges Präfix γα, wenn es eine Rechtsableitung 

S ⇒ ∗ r γAw ⇒r γαβw gibt. 

Gültige Items beschreiben Situationen während einer Rechtsanalyse. Das zuverlässige 

Präfix γα entspricht dem bisher bearbeiteten Teil der Eingabe. A → αβ könnte eine 

demnächst anzuwendende Produktion sein, wobei der Anteil α der rechten Seite 

bereits erzeugt wurde. 

Beispiel 37 

Gegeben sei die folgende startseparierte Grammatik für arithmetische Ausdrücke [WM96]: 

S → E 

E → E + T | T 

T → T * F | F 

F → ( E ) | id 

Wir geben für verschiedene Schritte der Ableitung einer Satzform zuverlässige Präfixe 

und für sie gültige Items an: 

a) S ⇒r E ⇒r E+T: 

E+ ist zuverlässiges Präfix und [E → E + .T] ist gültiges 

� �� 

Griff 

Item (γ,w leer). 

b) S ⇒∗ r E+T ⇒r E+ �� F : E+ ist wieder zuverlässiges Präfix und [T → .F] ist 

Griff 

gültiges Item (γ = E+). 

c) S ⇒∗ r E+F ⇒r E+id: E+ ist wieder zuverlässiges Präfix und [F → .id] ist 

gültiges Item (γ = E+). 

d) S ⇒ ∗ r (E+F) ⇒r (E+ (E) 

�� 

Griff 

): (E+ 

� �� 

γ 

( 

�� 

α 

Griff hinaus) und [F → (.E)] ist gültiges Item. 

ist zuverlässiges Präfix (nicht über den 

Satz 9 

Zu jedem zuverlässigen Präfix gibt es mindestens ein gültiges Item. 

Wir konstruieren nun einen endlichen Automaten, der zuverlässige Präfixe erkennt 

und darüber hinaus in seinen Zuständen Informationen über mögliche Reduktionen 

enthält. 

88


Definition 38 

Sei G = (VN,VT,P,S ′ ) startseparierte kontextfreie Grammatik (S ′ → S sei die einzige 

Produktion, die S ′ enthält). Sei char(G) = (Qc,VN ∪ VT, ∆c,qc,Fc) mit 

Qc = ItG, 

qc = [S ′ → .S], 

Fc = vollstItG, 

∆c = {([A → α.Y β],Y, [A → αY.β]) | A → αY β ∈ P,Y ∈ VN ∪ VT } 

∪ {([A → α.Bβ],ε, [B → .γ]) | A → αBβ ∈ P,B → γ ∈ P } 

der charakteristische endliche Automat zu G. 

Die Zustände des charakteristischen endlichen Automaten werden durch die Items 

aus ItG gebildet. Endzustände sind die Zustände, die vollständigen Items entsprechen. 

Es gibt zwei Arten von Übergängen in diesem Automaten. Steht der “.”, der die 

aktuelle Analysesituation kennzeichnet, vor einem Symbol Y (Terminal- oder Nichtterminalsymbol), 

kann der Punkt hinter das Y bewegt werden. Dieser Übergang ist 

mit Y beschriftet und beschreibt, daß der Teil der Eingabe, der zu Y reduziert wird, 

analysiert wurde. Die zweite Art von Übergängen beschreibt die Ersetzung von Nichtterminalen 

durch ihre rechten Regelseiten. Steht der “.” vor einem Nichtterminal B, 

geht eine ε-Kante vom aktuellen Zustand zu einem neuen Zustand [B → .γ] über: B 

wurde durch die rechte Regelseite γ ersetzt, und es wurde noch kein Teilwort von γ 

analysiert (Expansionsübergänge). 


Abbildung 3.17 enthält den charakteristischen endlichen Automaten für die Grammatik 

aus Beispiel 37. Jede “Zeile” aus Items entspricht dem “Schieben” des “.” durch 

eine Produktion der Grammatik. Am Ende der Zeilen befinden sich die vollständigen 

Items. 

Satz 10 

Ist γ ∈ (VN ∪ VT) ∗ und q ∈ Qc, dann gilt (qc,γ) ⊢ ∗ (q,ε) genau dann, wenn γ ein 

zuverlässiges Präfix und q ein gültiges Item für γ ist. 

Es gilt also: 

1. Der Automat erkennt genau zuverlässige Präfixe, wenn man alle Zustände als 

Endzustände betrachtet. 

2. Endzustände sind vollständige Items, das sind solche, die maximal langen zuverlässigen 

Präfixen entsprechen (d.h. wird während der Analyse ein vollständiges 

Item erreicht, muß reduziert werden). Wir können Items also wie folgt interpretieren: 

[A → α.β]: Griff ist unvollständig (später: Shift-Schritt) 

[A → α.]: Griff ist vollständig, also reduzieren. 

89


ε 

ε 

ε 

E 

[S .E] [S E.] 

ε 

ε ε 

E 

+ T 

[E .E+T] [E E.+T] [E E+.T] [E E+T.] 

ε 

ε 

T 

[E .T] [E T.] 

ε 

ε 

ε 

T * F 

[T .T*F] [T T.*F] [T T*.F] [T T*F.] 

ε 

ε 

F 

[T .F] [ T F.] 

ε 

ε 

( E ) 

[F .(E)] [F (.E)] [F (E.)] [F (E).] 

ε 

id 

[F . id ] [F id .] 

Abbildung 3.17: Beispiel eines charakteristischen endlichen Automaten 

Die Items (und damit die Zustände des Automaten) enthalten somit Informationen 

für die Analyse. 

Beweis 

“⇒”: 

Induktion über die Länge der Berechnung. Bezeichne ⊢ n einen Übergang in char(G) 

in n Schritten. 

Induktionsanfang: (qc,γ) ⊢ 0 (qc,ε) gilt nur für γ = ε, ε ist zuverlässiges Präfix, 

qc = [S ′ → .S] ist gültiges Item für ε. 

Induktionsannahme: Die Behauptung gelte für alle Berechnungen der Länge kleiner 

als n. Sei nun (qc,γ) ⊢ n (q,ε). 

Induktionsschritt: 

1. Fall: (qc,γ) ⊢ n−1 (p,ε) ⊢ (q,ε), d.h. der letzte Schritt war ein ε-Übergang. Dann 

haben p und q die Form p = [Y → α.Xβ], q = [X → .δ]. Nach Induktionsannahme 

ist γ zuverlässiges Präfix und p gültig für γ. Dann ist nach Definition 37 auch q gültig 

für γ (sich vor X zu befinden bedeutet, sich vor δ zu befinden). 

2.Fall: γ = γ ′ X, (qc,γ ′ X) ⊢ n−1 (p,X) ⊢ (q,ε). Nach Induktionsannahme ist γ ′ zuverlässiges 

Präfix und p gültig für γ ′ , da (qc,γ ′ ) ⊢ n−1 (p,ε). Dann haben p und q die 

Form [Y → α.Xβ] bzw. [Y → αX.β]. Da p gültig ist für γ ′ , gibt es eine Rechtsableitung 

S ⇒ ∗ r δY u ⇒r δαXβu mit γ ′ = δα. Dann ist γ = γ ′ X ein zuverlässiges Präfix 

und q gültig für γ. 

90


“⇐”: 

Induktion über die Länge von γ. 

Induktionsanfang: γ = ε: alle gültigen Items für das zuverlässige Präfix ε haben die 

Form q = [X → .α] mit S ′ ⇒ ∗ r Xβ (noch nichts erzeugt). Nach Konstruktion von 

char(G) gilt dann (qc,ε) ⊢ ∗ (q,ε) (nur Expansionsübergänge verwendet). 

Induktionsannahme: Die Behauptung gelte für alle zuverlässigen Präfixe der Länge 

kleiner als n und alle für sie gültigen Items q. 

Induktionsschritt: Sei γX zuverlässiges Präfix der Länge n und q gültiges Item für 

γX, q = [A → β1.β2]. Dann gibt es eine Rechtsableitung S ⇒ ∗ r αAw ⇒r αβ1β2w und 

γX = αβ1. Wir unterscheiden die folgenden beiden Fälle: entweder β1 �= ε, d.h. wir 

befinden uns noch in der Analyse für X; oder β1 = ε, d.h. γX = α, also ist X bereits 

auf dem Keller. 

1. Fall: β1 = γ ′ X, d.h. γ = αγ ′ . Dann ist [A → γ ′ .Xβ2] gültig für das zuverlässige 

Präfix γ. Nach Konstruktion von char(G) und Induktionsannahme gilt dann 

(qc,γX) ⊢ ∗ ([A → γ ′ .Xβ2],X) ⊢ ([A → γ ′ X.β2],ε). 

2. Fall: β1 = ε, d.h. α = γX (X “ist auf dem Keller”, d.h. es gab einen Schritt 

in der Rechtsanalyse, in dem das X dorthin gekommen ist). Wir betrachten in der 

Rechtsableitung S ′ ⇒ ∗ r αAw den Schritt, in dem das Vorkommen von X in α eingeführt 

wurde: S ⇒ ∗ r µBy ⇒r µνXρy mit µν = γ. Jeder spätere Schritt ersetzt 

nur Nichtterminale rechts von X (sonst handelt es sich nicht um eine Rechtsableitung). 

Dann ist [B → ν.Xρ] gültiges Item für das zuverlässige Präfix γ = µν. Nach 

Induktionsannahme und Konstruktion von char(G) gilt: 

(qc,γX) ⊢ ∗ ([B → ν.Xρ],X) ⊢ ([B → νX.ρ],ε) ⊢ ∗ ([A → β1.β2],ε) 

(beide Items sind gültig für γX). � 

Korollar 1 

Die Sprache der zuverlässigen Präfixe einer kontextfreien Grammatik ist regulär. 

Der charakteristische endliche Automat einer kontextfreien Grammatik ist nichtdeterministisch. 

Um den Automaten in der deterministischen Bottom-Up-Syntaxanalyse 

verwenden zu können, müssen wir ihn determinisieren. Hierzu kann das auf Seite 23 

angegebene Verfahren der Potenzmengenkonstruktion verwendet werden. 

Definition 39 

Der sich durch die Potenzmengenkonstruktion aus char(G) ergebende deterministische 

endliche Automat (Qd,VN ∪ VT,δd,qd,Fd) wird LR-DEA(G) genannt. 


Wir führen das Verfahren der Potenzmengenkonstruktion für den charakteristischen 

endlichen Automaten aus Abbildung 3.17 durch. 

91


Der Startzustand des LR-DEA(G) ergibt sich laut dem Verfahren der Potenzmengenkonstruktion 

aus der Menge der ε-Folgezustände des Startzustands des NEA (also 

des char(G)). Daher ist der Startzustand 

S0 = {[S → .E], [E → .E+T], [E → .T], [T → .T ∗F], [T → .F], 

[F → .(E)], [F → .id]}. 

Der Folgezustand eines Zustands unter einem Symbol a ergibt sich aus den ε-Folgezuständen 

der Folgezustände der Elemente unter a im NEA. Die Übergänge [S → .E] E → [S → 

E.] und [E → .E+T] E → [E → E.+T] sind die einzigen Übergänge von Zuständen 

aus S0 unter E. Daher bilden wir aus den Folgezuständen einen neuen Zustand 

S1 = {[S → E.], [E → E.+T]}. Von den Zuständen in S1 gehen keine ε-Kanten 

aus, so daß keine weiteren Zustände in S1 aufgenommen werden müssen. Im LR- 

E 

DEA(G) gilt also: S0 → S1. 

Die übrigen Zustände des LR-DEA(G) werden analog gebildet. Abbildung 3.18 enthält 

den LR-DEA(G) für den char(G) aus Abbildung 3.17. 

Endzustände des LR-DEA(G) sind die Zustände, die Endzustände des char(G) (also 

vollständige Items) enthalten. 

Es gilt: 

1. Die Zustände des LR-DEA(G) einer Grammatik G zerlegen die Menge der zuverlässigen 

Präfixe in endlich viele disjunkte Teilmengen (die Teilmengen werden 

durch die Zustände dargestellt). Für jedes zuverlässige Präfix gibt es genau 

einen Zustand, in den der Parser durch die Analyse dieses Präfixes gelangt. 

2. Sei γ zuverlässiges Präfix, p(γ) der Zustand, in den der LR-DEA(G) mit γ 

übergeht. Dann enthält p(γ) genau alle gültigen Items für γ, also alle möglichen 

Analysesituationen, die am Ende der Analyse von γ vorliegen können 

(Eigenschaft der Potenzmengenkonstruktion). 

Der folgende Algorithmus gibt an, wie der LR-DEA(G) direkt aus der Grammatik 

G erzeugt werden kann. 

Direkte Konstruktion des LR-DEA(G). 

Eingabe: startseparierte kontextfreie Grammatik G = (VN,VT,P,S ′ ) 

Ausgabe: LR-DEA(G) = (Qd,VN ∪ VT,δd,qd,Fd) 

Verfahren: 

1 var q,q ′ : set of item ; 

2 

3 function Start : set of item ; 

4 return ({[S ′ → .S]}) ; 

5 

6 function Closure (s : set of item) : set of item }; 

92

7 begin 

8 q := s; 


9 foreach ([X → α.Y β] ∈ q ∧ Y → γ ∈ P) ∧ ([Y → .γ] /∈ q) do 

10 q := q ∪ {[Y → .γ]} 

11 od }; 

12 return q ; 

13 end; 

14 

15 function Successor (s : set of item , Y : VN ∪ VT ) : set of 

item ; 

16 return {[X → αY.β] | [X → α.Y β] ∈ s}; 

17 

18 begin (∗ Hauptprogramm ∗) 

19 Qd := {Closure(Start)}; 

20 δd := ∅; 

21 foreach (q ∈ Qd) ∧ (X ∈ VN ∪ VT) do 

22 q ′ := Closure(Successor(q,X)); 

23 if q ′ �= ∅ then 

24 if q ′ /∈ Qd then 

25 Qd := Qd ∪ {q ′ } 

26 fi ; 

27 δd := δd ∪ {q X → q ′ } 

28 fi 

29 od 

30 end. 

Die Funktion Start liefert den Anfangszustand des LR-DEA(G). Die Funktion Closure 

liefert zu einer Menge s von Items eine Menge von Items, die die ε-Folgezustände 

der Zustände von s beinhalten. Successor berechnet für einen Zustand s, also eine 

Menge von Items, den Nachfolgezustand unter dem Symbol Y . 

Im Hauptprogramm wird zuerst die Zustandsmenge Qd des LR-DEA(G) mit dem 

Startzustand initialisiert. Der Startzustand enthält das Item [S ′ → .S] (durch Aufruf 

von Start) und dessen ε-Folgezustände (durch Aufruf von Closure). Dann werden 

in einer Schleife für jeden Zustand der aktuellen Menge Qd die Folgezustände unter 

dem jeweiligen Symbol X berechnet 1 . Ist dieser Zustand nicht leer und existiert er 

noch nicht in Qd, wird er in Qd aufgenommen. Die Übergangsrelation δd wird um 

den neuen Übergang erweitert. 

Wir konstruieren jetzt einen Kellerautomaten, in dem dieser endliche Automat “eingebaut” 

ist. Dieser Kellerautomat ist im allgemeinen noch nicht deterministisch. Zur 

1 foreach wird als “für jede Kombination aus q und X” interpretiert 

93


S 

0 

E 

T 

F 

( 

id 

S 

1 

S 

5 

S 

3 

F 

S 

4 

( 

T 

S 

2 

S0 = { [S → .E], 

[E → .E+T], 

[E → .T], 

[T → .T ∗F], 

[T → .F], 

[F → .(E)], 

[F → .id]} 

S1 = { [S → E.], 

[E → E.+T]} 

S2 = { [E → T.], 

[T → T.∗F]} 

S3 = { [T → F.]} 

S4 = { [F → (.E)], 

[E → .E+T], 

[E → .T], 

[T → .T ∗F], 

[T → .F], 

[F → .(E)], 

[F → .id]} 

94 

id 

+ 

F 

E 

( 

id 

S 

6 

+ 

T 

S 

8 

) 

( 

S 

11 

* 

id 

S5 = { [F → id.]} 

S6 = { [E → E+.T], 

[T → .T ∗F], 

[T → .F], 

[F → .(E)], 

[F → .id]} 

S7 = { [T → T ∗.F], 

[F → .(E)], 

[F → .id]} 

S8 = { [F → (E.)], 

[E → E.+T]} 

S9 = { [E → E+T.], 

[T → T.∗F]} 

S10 = { [T → T ∗F.]} 

S11 = { [F → (E).]} 

Abbildung 3.18: Beispiel eines LR-DEA. 

S 

9 

* 

F 

S S 

7 10


Vereinfachung betrachten wir die Ausgabe des Automaten nicht. 

Bei den bisherigen Kellerautomaten wurde der Keller so dargestellt, daß sich die 

Kellerspitze links befand. Da sich bei der Bottom-Up-Analyse die bereits gelesenen 

Zeichen so auf dem Keller befinden, daß das zuletzt gelesenen Zeichen an der Kellerspitze 

steht, verwenden wir eine Darstellung von Kellerautomaten, bei der die 

Kellerspitze rechts angegeben wird. Auf diese Weise kann der Griff auf dem Keller 

ohne die sonst notwendige Invertierung dargestellt werden. 

Definition 40 Ein Kellerautomat (ohne Ausgabe) ist ein Tupel M = (Σ, Γ, ∆,z0) 

mit 

• Σ endliche Menge (Eingabealphabet), 

• Γ endliche Menge (Kelleralphabet), 

• z0 ∈ Γ (Kellerstartsymbol), 

• ∆ ⊆ ((Σ ∪ {ε}) × Γ ≤k ) × Γ ∗ ,k ∈ N (endliche Übergangsrelation). 

Die Menge der Konfigurationen von M ist K = Σ ∗ ×Γ ∗ , die Anfangskonfiguration für 

w ∈ Σ ∗ lautet (w,z0), die Endkonfiguration ist (ε,ε). Die Schrittrelation ⊢M⊆ K×K 

ist definiert durch 

(aw,γα) ⊢M (w,γβ) gdw. ((a,α),β) ∈ ∆,a ∈ Σ ∪ {ε}. 

Definition 41 

Sei LR-DEA(G) = (Qd,VN ∪ VT,δd,qd,Fd). 

Sei K0 = (VT,Qd, ∆,qd) der Kellerautomat mit ∆ ⊆ ((VT ∪ {ε}) × Q ∗ d) × Q ∗ d 

definiert durch 

((a,q),qδd(q,a)) ∈ ∆ falls δd(q,a) definiert (Shift-Schritt), 

((ε,q0q1...qn),q0δd(q0,X)) ∈ ∆ falls [X → α.] ∈ qn, |α| = n (n ≥ 0) (Reduce- 

Schritt), 

((ε,qdq0),ε) ∈ ∆ falls [S ′ → S.] ∈ q0 (Erkennungsende). 

Eingabealphabet des Kellerautomaten K0 ist VT. Das Kelleralphabet von K0 bildet 

die Zustandsmenge Qd des LR-DEA(G), d.h. auf dem Keller von K0 können nur 

Zustände des LR-DEA(G) gespeichert werden. Das Kellerstartsymbol ist der Anfangszustand 

qd des LR-DEA(G). Die Übergangsrelation ∆ wird durch drei Arten 

von Übergängen gebildet: 

• In Übergängen der Form ((a,q),qδd(q,a)) wird das nächste Eingabezeichen a 

gelesen und der entsprechende Nachfolgezustand δd(q,a) auf den Keller gelegt 

(Kellerspitze ist rechts). Dies ist genau dann möglich, wenn der aktuelle Zustand 

q an der Spitze des Kellers mindestens ein Item der Form [X → ....a...] enthält. 

• In Übergängen der Form ((ε,q0q1...qn),q0δd(q0,X)) liegt eine Folge q0q1...qn von 

n + 1 Zuständen (q0 bezeichnet einen beliebigen Zustand) mit der Kellerspitze 

qn vor. Falls qn als aktueller Zustand ein vollständiges Item [X → α.] enthält 

95


und die Länge von α n Symbole beträgt, werden die n obersten Zustände vom 

Keller entfernt und durch den Nachfolgezustand δd(q0,X) ersetzt. 

• Analog zum früher angegebenen Bottom-Up-Automaten soll die Termination 

einer Analyse möglich sein, wenn “$S” auf dem Keller liegt, d.h. qd und ein Zustand 

q0, der [S ′ → S.] enthält. Diese Situation heißt Erkennungsende. Wegen 

der Startseparierung kommt [S ′ → S.] nur in einem Zustand vor. Der Übergang 

((ε,qdq0),ε) beschreibt den Akzeptanzschritt des Kellerautomaten. Ist die Eingabe 

leer und auf dem Keller liegen nur qd und q0, werden diese Zustände vom 

Keller entfernt. Da nun Eingabe und Keller leer sind, hält der Kellerautomat 

an. 

Der Kellerautomat “befindet sich” immer in dem Zustand, der gerade oben auf 

dem Keller liegt. qd spielt die Rolle des $ beim früher angegebenen Bottom-Up- 

Analyseautomaten (und gleichzeitig des Anfangszustands des Kellerautomaten), deshalb 

ist es richtig, daß qd immer auf dem Keller bleibt. Nur beim Erkennungsende 

wird qd vom Keller entfernt. 

Für jedes gelesene Symbol der Eingabe wird ein Zustand auf den Keller gelegt, und 

zwar der Zustand, der vom aktuellen Zustand aus im LR-DEA(G) mit einer Kante 

zu erreichen ist, die mit dem gelesenen Symbol beschriftet ist. Enthält der aktuelle 

Zustand ein vollständiges Item, kann eine Reduktion durchgeführt werden. Dabei 

werden so viele Zustände vom Keller entfernt, wie die zugehörige Produktion Symbole 

auf der rechten Regelseite besitzt. Hierdurch wird ein Zustand q0 Kellerspitze. 

Nun wird der Folgezustand von q0 unter dem Nichtterminal X (also der linken Seite 

der Produktion) auf den Keller gelegt. Eine Eingabe wird erkannt, wenn der Kellerautomat 

nach einem Erkennungsende-Schritt mit leerer Eingabe und leerem Keller 

hält. Ein Problem tritt auf, wenn der Zustand q0 noch weitere Items enthält (siehe 

folgendes Beispiel), da dann der Automat nicht deterministisch das Ende der Analyse 

erkennen kann. Ein solcher Zustand ist ungeeignet (siehe Definition 42). 


Wir geben die Übergangsrelation des Kellerautomaten K0 für den LR-DEA(G) aus 

Abbildung 3.18 an. 

96 

• Shift-Schritte: 

(( id,S0),S0S5) (( (,S0),S0S4) (( +,S1),S1S6) 

(( ∗,S2),S2S7) (( (,S4),S4S4) (( id,S4),S4S5) 

(( id,S6),S6S5) (( (,S6),S6S4) (( (,S7),S7S4) 

(( id,S7),S7S5) (( +,S8),S8S6) (( ),S8),S8S11) 

(( ∗,S9),S9S7) 

• Reduce-Schritte: (zu jedem Schritt wird die Produktion angegeben, die diesem 

Reduktionsschritt entspricht)

((ε,S0S1S6S9),S0S1) (E → E+T) 

((ε,S4S8S6S9),S4S8) (E → E+T) 

((ε,S0S2),S0S1) (E → T) 

((ε,S4S2),S4S8) (E → T) 

((ε,S0S2S7S10),S0S2) (T → T ∗F) 

((ε,S4S2S7S10),S4S2) (T → T ∗F) 

((ε,S6S9S7S10),S6S9) (T → T ∗F) 

((ε,S0S3),S0S2) (T → F) 

((ε,S4S3),S4S2) (T → F) 

((ε,S6S3),S6S9) (T → F) 

((ε,S0S4S8S11),S0S3) (F → (E)) 

((ε,S4S4S8S11),S4S3) (F → (E)) 

((ε,S6S4S8S11),S6S3) (F → (E)) 

((ε,S7S4S8S11),S7S10) (F → (E)) 

((ε,S0S5),S0S3) (F → id) 

((ε,S4S5),S4S3) (F → id) 

((ε,S6S5),S6S3) (F → id) 

((ε,S7S5),S7S10) (F → id) 

((ε,S0S1),ε) (S → E) (Erkennungsende), 


In der folgenden Tabelle ist eine Ableitung des Kellerautomaten für das Eingabewort 

id+id*id angegeben (die Kellerspitze ist rechts): 

Eingabe 

id + id * id S0 

Kellerinhalt Ausgabe 

+ id * id S0 S5 

ε 

+ id * id S0 S3 

F → id 

+ id * id S0 S2 

T → F 

+ id * id S0 S1 

E → T 

id * id S0 S1 S6 

ε 

* id S0 S1 S6 S5 ε 

* id S0 S1 S6 S3 F → id 

* id S0 S1 S6 S9 T → F 

id S0 S1 S6 S9 S7 ε 

ε S0 S1 S6 S9 S7 S5 ε 

ε S0 S1 S6 S9 S7 S10 F → id 

ε S0 S1 S6 S9 T → T ∗F 

ε S0 S1 E → E+T 

ε ε accept 

Der Kellerautomat ist nichtdeterministisch, da im Zustand S1 des LR-DEA(G) neben 

dem Item [S → E.], das das Erkennungsende signalisiert, noch ein weiteres Item 

97


enthalten ist. Befindet sich der Automat im Zustand S1, muß nichtdeterministisch 

entschieden werden, ob das Erkennungsende oder ein Shift-Schritt ausgeführt werden 

soll. So hätte in der fünften Zeile der Tabelle mit der Ableitung auch das Erkennungsende 

ausgewählt werden können, was zu einem Fehler bei der Analyse geführt 

hätte. 

Der Kellerautomat K0 ist nichtdeterministisch, wenn ein Zustand q des LR-DEA(G) 

1. sowohl Shift- als auch Reduce-Übergänge erlaubt (Shift-Reduce-Konflikt), 

2. zwei verschiedene Reduce-Übergänge gemäß zweier verschiedener Produktionen 

hat (Reduce-Reduce-Konflikt). 

Im ersten Fall gibt es mindestens ein “Lese-Item” [X → α.aβ] und mindestens ein 

vollständiges Item in q. Im zweiten Fall gibt es mindestens zwei vollständige Items 

in q. 

Zustände, die solche Konflikte enthalten, nennen wir ungeeignet. 

Definition 42 

Sei Qd Zustandsmenge von LR-DEA(G). q ∈ Qd heißt ungeeignet, wenn q ein Item 

der Form [X → α.aβ], a ∈ VT, und ein vollständiges Item der Form [Y → γ.] enthält 

(Shift-Reduce-Konflikt) oder wenn q zwei verschiedene vollständige Items [Y → α.] 

und [Z → β.] enthält (Reduce-Reduce-Konflikt). 

Beispiel 41 

Die Zustände S1,S2 und S9 des LR-DEA(G) in Abbildung 3.18 sind ungeeignet, da 

jeder von ihnen einen Shift-Reduce-Konflikt enthält. 

Satz 11 

Eine kontextfreie Grammatik G ist genau dann eine LR(0)-Grammatik, wenn LR- 

DEA(G) keine ungeeigneten Zustände besitzt. 

Beweis 

“⇒”: 

Sei G LR(0)-Grammatik. Wir nehmen an, daß LR-DEA(G) einen ungeeigneten Zustand 

p enthält. Wir unterscheiden zwei Fälle: 

1. Fall: p enthält einen Reduce-Reduce-Konflikt. Dann hat p mindestens zwei verschiedene 

Reduce-Items [X → β.], [Y → δ.]. p ist eine nicht-leere Menge von zuverlässigen 

Präfixen zugeordnet (mit denen man nach p gelangt; nach Konstruktion 

von LR-DEA(G) sind alle Zustände erreichbar). Sei γβ ein solches zuverlässiges Präfix 

(nämlich das, das zu dem ersten Item paßt). Beide Reduce-Items sind gültig für γβ, 

d.h. 

98

S ′ 

⇒ ∗ r γXw ⇒r γβw 

⇒ ∗ r νY y ⇒r νδy 


mit γβ = νδ sind verschiedene Rechtsableitungen, was ein Widerspruch zur LR(0)- 

Eigenschaft ist. 

2. Fall: p enthält einen Shift-Reduce-Konflikt: analog. 

“⇐”: 

Wir nehmen an, daß LR-DEA(G) keine ungeeigneten Zustände enthält. Wir betrachten 

die Rechtsableitungen 

S ′ 

⇒ ∗ r αXw ⇒r αβw 

⇒ ∗ r γY x ⇒r αβy 

und zeigen, daß α = γ,X = Y,x = y gilt. Mit αβ erreicht LR-DEA(G) einen Zustand 

p. Da p nicht ungeeignet, enthält p genau ein Reduce-Item, und zwar [X → β.], und 

kein Shift-Item. p enthält alle für αβ gültigen Items, deshalb ist α = γ,X = Y und 

x = y. � 

Mit dem oben konstruierten Kellerautomaten K0 haben wir also ein Parse-Verfahren 

für LR(0)-Grammatiken. Allerdings ist LR(0) für die Praxis zu eingeschränkt, obwohl 

LR(0) mächtiger ist als LL(0). Daher erweitern wir unser Konstruktionsverfahren für 

den Fall k ≥ 1. Dazu müssen wir den lookahead miteinbeziehen, indem wir die Items 

um “passende” Vorausschaumengen erweitern. Die Auswahl des nächsten Schrittes 

kann dann in Abhängigkeit von diesen Vorausschaumengen getroffen werden. 

Definition 43 

Sei G kontextfreie Grammatik. [A → α.β,L] heißt LR(k)-Item von G, wenn A → 

αβ ∈ P und L ⊆ V ≤k 

T gilt. A → α.β heißt dann Kern, L Vorausschaumenge des 

Items. 

Ein LR(k)-Item [A → α.β,L] heißt gültig für ein zuverlässiges Präfix γα, falls es 

für alle u ∈ L eine Rechtsableitung S ⇒ ∗ r γAw ⇒r γαβw mit u = k : w gibt. 

Die bisher betrachteten Items sind LR(0)-Items, wenn wir [A → α.β, {ε}] mit [A → 

α.β] identifizieren. 

Analog zu den LR(0)-Items definieren wir Shift-Reduce- und Reduce-Reduce-Konflikte. 

Dabei werden die Vorausschaumengen mit einbezogen. 

Definition 44 

Sei I eine Menge von LR(1)-Items. I enthält einen Shift-Reduce-Konflikt, wenn es 

99


ein Item [X → α.aβ,L1] und ein Item [Y → γ.,L2] enthält, und es gilt a ∈ L2. 

I enthält einen Reduce-Reduce-Konflikt, wenn es zwei Items [X → α.,L1] und [Y → 

β.,L2] gibt mit L1 ∩ L2 �= ∅. 

Konstruktion von LR(1)-Parsern 

Wir ermöglichen jetzt dem Parser, bei seinen Entscheidungen in ungeeigneten Zuständen 

(im LR(0)-Sinn) den lookahead mit den Vorausschaumengen der LR(1)-Items zu vergleichen: 

• Enthält ein LR(1)-Parser-Zustand mehrere vollständige Items, so liegt trotzdem 

kein Reduce-Reduce-Konflikt vor, wenn ihre Vorausschaumengen disjunkt sind. 

• Enthält ein LR(1)-Parser-Zustand ein vollständiges Item [X → α.,L] und ein 

Shift-Item [Y → β.aγ,L ′ ], so liegt kein Shift-Reduce-Konflikt zwischen ihnen 

vor, wenn L das Symbol a nicht enthält. 

Im folgenden sei k = 1 und die zu analysierende Eingabe stets durch $ abgeschlossen. 

Daher sind die Vorausschaumengen immer Teilmengen von VT ∪ {$}. 

Analog zum auf Seite 92 angegebenen Algorithmus für LR(0)-Items läßt sich auch 

für LR(1)-Items ein Algorithmus LR(1)-GEN angeben, der die Berechnung des charakteristischen 

endlichen Automaten für eine LR(1)-Grammatik G durchführt. 

Algorithmus LR(1)-GEN. 

Eingabe: startseparierte kontextfreie Grammatik G = (VN,VT,P,S) 

Ausgabe: charakteristischer endlicher Automat eines kanonischen LR(1)-Parsers 

Verfahren: 

1 var q,q ′ : set of item ; 

2 

3 function Start : set of item ; 

4 return ({[S ′ → .S, {$}]}) ; 

5 

6 function Closure (s : set of item) : set of item ; 

7 begin 

8 q := s; 

9 foreach ([X → α.Y β,L] ∈ q ∧ Y → γ ∈ P) do 

10 if exist ([Y → .γ,L ′ ] ∈ q) then 

11 replace [Y → .γ,L ′ ] by [Y → .γ,L ′ ∪ (FIRST(βL)\{ε})] 

12 else q := q ∪ {[Y → .γ,FIRST(βL)\{ε}]} 

13 fi 

14 od; 

15 return q 

100

16 end; 

17 


18 function Successor (s : set of item , Y : VN ∪ VT ) : set of 

item ; 

19 return {[X → αY.β,L] | [X → α.Y β,L] ∈ s}; 

20 

21 begin (∗ Hauptprogramm ∗) 

22 Q := {Closure(Start)}; 

23 δ := ∅; 

24 foreach (q ∈ Q) ∧ (X ∈ VN ∪ VT) {\ bf do 

25 q ′ := Closure(Successor(q,X)); 

26 if q ′ �= ∅ then 

27 if q ′ /∈ Q then 

28 Q := Q ∪ {q ′ } 

29 fi ; 

30 δ := δ ∪ {q X → q ′ } 

31 fi 

32 od 

33 end. 

Zur Funktion Closure: 

Ist [X → α.Y β,L] gültig für ein zuverlässiges Präfix δα und ist Y → γ eine Alternative 

für Y , dann muß auch [Y → .γ] für δα gültig sein (nach Definition 43). Dann 

kann in einer Rechtssatzform jedes Symbol auf δαγ folgen, daß aus FIRST(βL) ist 

(β könnte leer sein). ε soll nicht in Vorausschaumengen auftreten, da die Eingabe 

mit $ abgeschlossen ist. 

Zur Funktion Successor: 

Die Vorausschaumengen der Items sind erst bei der Auswahl von Reduce-Items 

von Bedeutung. Aus diesem Grund werden sie beim “Durchschieben”, also beim 

Übergang in einen Folgezustand, nicht modifiziert. Nach Definition 43 gilt: wenn 

[X → α.Y β,L] für γα gültig ist, dann ist [X → αY.β,L] gültig für γαY . 

Beispiel 42 

Wir betrachten wieder die aus Beispiel 37 auf Seite 88 bekannte Grammatik G zur 

Beschreibung arithmetischer Ausdrücke: 

S → E 

E → E + T | T 

T → T * F | F 

F → ( E ) | id 

In dem in Abbildung 3.18 angegebenen LR-DEA(G) sind die Zustände S1, S2 und S9 

ungeeignet, da sie jeweils einen Shift-Reduce-Konflikt enthalten. 

101


Wir berechnen die LR(1)-Items der Grammatik mit Hilfe des Algorithmus LR(1)- 

GEN auf Seite 100. 

Die Funktion Start liefert die Menge {[S → .E, {$}]}. Der Aufruf der Funktion Closure 

berechnet die ε-Folgezustände des Start-Items. Der “.” steht vor einem Nichtterminal 

E, also müssen wir die Items der Produktionen von E in den Anfangszustand 

des Automaten aufnehmen. Betrachten wir zunächst die Produktion E → E+T. Für 

die Vorausschaumenge dieses neuen Items ergibt sich β = ε und L = {$}, also ist 

das neue Item [E → .E+T, {$}]. In diesem Item steht der Punkt wieder vor dem 

Nichtterminal E, so daß wiederum die Items der Produktionen zu E aufgenommen 

werden müssen. Da das Item für den Kern E → .E+T schon in der Menge existiert, 

wird kein neues Item hinzugefügt, sondern die Vorausschaumenge aktualisiert. 

β = +T, also lautet das Item nun [E → .E+T, {$, +}]. Eine weitere Produktion von 

E ist E → T, so daß wir im ersten Schritt das Item [E → .T, {$}] und im zweiten 

das aktualisierte Item [E → .T, {$, +}] erhalten. Das letzte Item ergibt mit der Produktion 

T → T ∗F das neue Item 

[T → .T ∗F, {$, +, ∗}] und mit der Produktion T → F das Item 

[T → .F, {$, +, ∗}]. Letzteres ergibt mit der Produktion F → (E) das Item [F → 

.(E), {$, +, ∗}] (da β = ε in T → F). Dieses Item ergibt nichts neues, da der 

“.” hier vor einem Terminal steht. Entsprechend ergibt sich mit F → id das Item 

[F → .id, {$, +, ∗}]. 

Wir nennen die Menge dieser Items, die wir durch den Aufruf Closure(Start) generiert 

haben, S ′ 0. Diese Menge entspricht dem Anfangszustand des Automaten zu G 

und wird als erstes Element in die Zustandsmenge Q aufgenommen. 

In den weiteren Schritten des Verfahrens werden die übrigen Zustände des Automaten 

berechnet, z.B. 

Successor(S ′ 0,E) = {[S → E., {$}], [E → E.+T, {$, +}]} 

= Closure(Successor(S ′ 0,E)). 

Diesen Zustand nennen wir S ′ 1. Die Berechnung der anderen Zustände erfolgt analog. 

Wir geben hier nur die Zustände S ′ 0, S ′ 1, S ′ 2 und S ′ 9 an: 

102

S ′ 0 = { [S → .E, {$}], 

[E → .E+T, {$, +}], 

[E → .T, {$, +}], 

[T → .T ∗F, {$, +, ∗}], 

[T → .F, {$, +, ∗}], 

[F → .(E), {$, +, ∗}], 

[F → .id, {$, +, ∗}]} 

S ′ 1 = { [S → E., {$}], 

[E → E.+T, {$, +}]} 

S ′ 2 = { [E → T., {$, +}], 

[T → T.∗F, {$, +, ∗}]} 

... 

S ′ 9 = { [E → E+T., {$, +}], 

[T → T.∗F, {$, +, ∗}]} 


Im LR-DEA(G), der nur LR(0)-Items enthält, sind die Zustände S1, S2 und S9 

aufgrund von Shift-Reduce-Konflikten ungeeignet. Die Zustände S ′ 1, S ′ 2 und S ′ 9 des 

charakteristischen endlichen Automaten zu G enthalten diese Konflikte nicht mehr, 

da durch die Angabe von Vorausschaumengen (und damit der Einbeziehung des lookaheads) 

die Auswahl deterministisch getroffen werden kann. Zum Beispiel ist in S ′ 1 das 

+ nicht in der Vorausschaumenge des Reduce-Items enthalten, so daß bei einem + im 

lookahead ein Shift-Schritt und andernfalls ein Reduce-Schritt durchgeführt werden 

muß. 

Die Grammatik G zur Beschreibung arithmetischer Ausdrücke ist somit eine LR(1)- 

Grammatik. 

LR(1)-Parse-Tabellen 

Wie zuvor der LR-DEA(G) dient uns der charakteristische endliche Automat mit 

LR(1)-Items als Grundlage für einen Parser. Wir wollen den Parser diesmal nicht als 

Kellerautomaten, sondern in algorithmischer Form angeben. Dazu verwenden wir, 

analog zur Top-Down-Analyse, eine Parse-Tabelle. 

Die Zeilen der Tabelle sind mit den Zuständen der Zustandsmenge Q des charakteristischen 

LR(1)-Automaten beschriftet. Die Tabelle ist in zwei Teiltabellen untergliedert: 

die action-Tabelle und die goto-Tabelle. Die Spalten der action-Tabelle sind 

mit den Terminalsymbolen und dem Endezeichen $ beschriftet. Das Feld action[q,a] 

gibt an, welche Aktion ausgeführt werden soll, wenn der Parser sich im Zustand q 

befindet und im lookahead das Zeichen a steht. Mögliche Aktionen sind 

103


Q q 

VT ∪ {$} VN ∪ VT 

a X 

Parser-Aktion für 

(q,a) 

δ(q,X) 

action-Tabelle goto-Tabelle 

Abbildung 3.19: Struktur einer LR(1)-Parse-Tabelle. 

⎧ 

⎪⎨ 

action[q,a] = 

⎪⎩ 

shift 

reduce X → α 

error 

accept 

Die goto-Tabelle dient zum Nachschlagen der Folgezustände des charakteristischen 

LR(1)-Automaten. 

Das folgende Verfahren konstruiert eine LR(1)-action-Tabelle. 

Konstruktion der LR(1)-action-Tabelle. 

Eingabe: LR(1)-Zustandsmenge Q 

Ausgabe: action-Tabelle 

Verfahren: 

104 

1. Für jeden Zustand q ∈ Q und für jedes LR(1)-Item [K,L] ∈ q: 

• falls K = S ′ → S. und L = {$}: trage accept in action[q, $] ein, 

• sonst 

– falls K = X → α., trage reduce X → α in action[q,a] für alle a ∈ L 

ein, 

– falls K = X → α.aβ, trage shift in action[q,a] ein. 

2. Trage in jedes noch undefinierte Feld error ein.


Mit Hilfe der Parse-Tabelle kann der folgende Parse-Algorithmus die Analyse eines 

Eingabeworts deterministisch durchführen. 

LR(1)-Parse-Algorithmus. 

Eingabe: aus der action- und der goto-Tabelle bestehende LR(1)-Parse-Tabelle 

Ausgabe: Rechtsableitung von w, falls w ∈ L(G), sonst Fehlermeldung 

Verfahren: 

Anfangskonfiguration: 

q0 liegt auf dem Keller (q0 ist Anfangszustand des oben konstruierten charakteristischen 

endlichen Automaten), w$ steht im Eingabepuffer und der Eingabezeiger steht 

auf dem ersten Zeichen von links. 

1 repeat 

2 s e i q Zustand an der Spitze des Kellers und a aktuelles 

Eingabesymbol 

3 if action[q,a] = shift then 

4 lege goto[q,a] auf den Keller und r”ucke den 

Eingabezeiger vor 

5 else if action[q,a] = reduce X → α then begin 

6 entferne |α| Eintr”age vom Keller −− s e i nun q ′ oberster 

Kellereintrag ; 

7 lege goto[q ′ ,X] auf den Keller ; gib X → α aus 

8 end 

9 else if action[q,a] = accept then return 

10 else (∗ action[q,a] = error ∗) error 

11 end 

SLR(1), LALR(1)-Analyse 

Bei der Konstruktion eines LR(1)-Parsers ergibt sich das Problem, daß im allgemeinen 

mehr Zustände erzeugt werden, als dies bei der Generierung eines LR(0)-Parsers 

der Fall ist. Die Ursache hierfür ist die in den Zuständen enthaltene Information über 

den Linkskontext, die sich über die Vorausschaumenge fortpflanzt und ein Aufsplitten 

der Zustände verursacht (siehe Definition 37). 

Beispiel 43 (vereinfachte C-Zuweisung) 

Wir betrachten die folgende Grammatik zur Beschreibung des (vereinfachten) Zuweisungsoperators 

der Sprache C [KR90]: 

S’ → S 

S → L = R | R 

L → * R | id 

R → L 

105


S0 = { [S ′ → .S], 

[S → .L=R], 

[S → .R], 

[L → .∗R], 

[L → .id], 

[R → .L]} 

S1 = { [S ′ → S.]} 

S2 = { [S → L.=R], 

[R → L.]} 

S3 = { [S → R.]} 

S4 = { [L → ∗.R], 

[R → .L], 

[L → .∗R], 

[L → .id]} 

S5 = { [L → id.]} 

S6 = { [S → L=.R], 

[R → .L], 

[L → .∗R], 

[L → .id]} 

S7 = { [L → ∗R.]} 

S8 = { [R → L.]} 

S9 = { [S → L=R.]} 

Abbildung 3.20: Zustandsmenge des LR-DEA der Grammatik zur Beschreibung der 

C-Zuweisung aus Beispiel 43. 

Nach Anwendung des Verfahrens zur Berechnung des LR-DEAs auf Seite 92 erhalten 

wir die in Abbildung 3.20 angegebene Zustandsmenge (zur Verbesserung der Lesbarkeit 

lassen wir die Mengenklammern bei einelementigen Vorausschaumengen weg). 

Aufgrund der Differenzierung nach Vorausschaumengen werden die Zustände des LR- 

DEA in mehrere Zustände des LR(1)-Automaten aufgesplittet. Zum Beispiel wird der 

Zustand S4 aus Abbildung 3.20 in die Zustände I4 und I11 in Abbildung 3.21 aufgeteilt, 

deren Items dieselben Kerne, aber unterschiedliche Vorausschaumengen besitzen. Der 

LR(1)-Automat ist in Abbildung 3.22 dargestellt. 

Daher ergeben sich die folgenden Beziehungen zwischen LR(0)- und LR(1)-Items: 

S0 ∼ I0 S1 ∼ I1 S2 ∼ I2 S3 ∼ I3 S4 ∼ I4 und I11 

S5 ∼ I5 und I12 S6 ∼ I6 S7 ∼ I7 und I13 S8 ∼ I8 und I10 S9 ∼ I9 

Im LR-DEA in Abbildung 3.20 tritt das LR(0)-Item [R → .L] in den Zuständen S0 

und S4 auf. Durch das Shiften eines L gelangen wir aus beiden Zuständen in den 

Zustand S8. In Abbildung 3.21 unterscheiden sich die LR(1)-Items [R → .L, $] in 

I0 und [R → .L, {=, $}] in I4 durch ihre Vorausschaumengen. Aus I0 kann ein L- 

Übergang nach I10 erfolgen, aus I4 ein Übergang nach I8. Befinden wir uns also im 

Zustand I10, wissen wir eindeutig, daß wir aus I0 gekommen sind. Befinden wir uns 

im Zustand I8, sind wir aus I4 gekommen. Auf diese Weise enthalten die Zustände 

106

I0 = { [S ′ → .S, $], 

[S → .L=R, $], 

[S → .R, $], 

[L → .∗R, {=, $}], 

[L → .id, {=, $}], 

[R → .L,$]} 

I1 = { [S ′ → S., $]} 

I2 = { [S → L.=R, $], 

[R → L.,$]} 

I3 = { [S → R., $]} 

I4 = { [L → ∗.R, {=, $}], 

[R → .L, {=, $}], 

[L → .∗R, {=, $}], 

[L → .id, {=, $}]} 

I5 = { [L → id., {=, $}]} 

I6 = { [S → L=.R, $], 

[R → .L,$], 

[L → .∗R, $], 

[L → .id, $]} 

I7 = { [L → ∗R., {=, $}]} 

I8 = { [R → L., {=, $}]} 

I9 = { [S → L=R., $]} 

I10 = { [R → L.,$]} 

I11 = { [L → ∗.R, $], 

[R → .L,$], 

[L → .∗R, $], 

[L → .id, $]} 

I12 = { [L → id.,$]} 

I13 = { [L → ∗R., $]} 


Abbildung 3.21: Zustandsmenge des charakteristischen endlichen Automaten mit 

LR(1)-Items zur Grammatik aus Beispiel 43. 

des LR(1)-Parsers Informationen über den Linkskontext, also die bisherige Ableitung. 

Dies ist im LR-DEA nicht möglich. Wenn wir uns im Zustand S8 befinden, können 

wir nicht unterscheiden, ob wir uns zuvor in S0 oder in S4 befunden haben. 

Die durch die Einführung von Vorausschaumengen entstehende Aufsplittung von 

Zuständen ist bei der Analyse von realen Programmiersprachen ein wirkliches Problem, 

da die Zustandsmenge drastisch ansteigen kann (von hunderten zu tausenden 

von Zuständen). 

Aus diesem Grund verwendet man oft Teilklassen der LR(k)-Sprachen und Zustandsmengen, 

die die gleiche Größe haben wie die von LR(0)-Grammatiken. Diese Teilklassen 

sind die SLR(k) (simple LR(k)) und die LALR(k)-Sprachen (lookahead LR(k)). 

SLR(1)-Parser: 

Wir gehen vom LR-DEA eines LR(0)-Parsers aus. Die Idee bei den SLR(1)-Parsern 

ist, als Vorausschaumenge eines Items die FOLLOW1-Menge des Nichtterminals zu 

verwenden, das in dem betreffenden Item auf der linken Seite des Kerns steht. 

Der Aufbau einer SLR(1)-Parse-Tabelle ist zu dem einer LR(1)-Tabelle identisch 

(siehe Abbildung 3.19). Wir modifizieren das Konstruktionsverfahren für die action- 

Tabelle auf Seite 104 wie im folgenden angegeben. Der Parse-Algorithmus auf Seite 

107


S 

I I 

0 1 

L = 

R 

I I I 

id 

R 

* 

I 

R 

I I 

id 

I 

3 

2 6 9 

4 7 

5 

* 

L 

I 8 

* 

L 

id 

I 

L 

I I 

11 

R 

id 

Abbildung 3.22: Charakteristischer endlicher LR(1)-Automat zur Grammatik aus 

Beispiel 43. 

108 

I 

10 

12 

* 

13

105 wird unverändert übernommen. 


Konstruktion der SLR(1)-action-Tabelle. 

Eingabe: LR(0)-Zustandsmenge Q 

Ausgabe: action-Tabelle 

Verfahren: 

1. Für jeden Zustand q ∈ Q und für jedes [K] ∈ q: 

• falls K = S ′ → S.: trage accept in action[q, $] ein, 

• sonst 

– falls K = X → α., trage reduce X → α in action[q,a] für alle a ∈ 

FOLLOW(X) ein, 

– falls K = X → α.aβ, trage shift in action[q,a] ein. 

2. Trage in jedes noch undefinierte Feld error ein. 

Da für jedes Nichtterminal die FOLLOW1-Menge eindeutig bestimmt ist, kommt 

es nicht zum Aufsplitten von Zuständen, so daß die Zustandsmenge eines SLR(1)- 

Parsers gegenüber der eines LR(0)-Parsers unverändert bleibt. 

Nachteilig ist, daß nicht für alle LR(1)-Sprachen ein SLR(1)-Parser existiert, da durch 

die “Vergröberung” der Vorausschaumengen der Items ein Informationsverlust entsteht, 

wie im folgenden Beispiel zu sehen ist. 


In Abbildung 3.20 ist S2 der einzige ungeeignete Zustand. Wir berechnen die Zustandsmenge 

des charakteristischen endlichen Automaten mit SLR(1)-Items (Abbildung 

3.23). Es gilt FOLLOW1(S) = {$} und FOLLOW1(L) = FOLLOW1(R) = 

{=, $}. Bei der Erweiterung des vollständigen Items [R → L.] um die Vorausschaumenge 

{=, $} bleibt der Shift-Reduce-Konflikt aus S2 in S ′ 2 erhalten, da das zu lesende 

Symbol “=” in der Vorausschaumenge des vollständigen Items enthalten ist. Daher 

ist die Grammatik in Beispiel 43 keine SLR(1)-Grammatik. 

LALR(1)-Parser: 

Bei der Konstruktion eines LR(1)-Parsers kann es Zustände geben, die bzgl. der 

Kerne der Items übereinstimmen (z.B. die Zustände I4 und I11 in Abbildung 3.21). 

Um die Zustandsmenge zu verkleinern, kann man versuchen, diese Zustände zu einem 

Zustand zusammenzufassen, indem man die Vorausschaumengen der Items mit 

gleichem Kern vereinigt. Die Zustandszahl eines Automaten, bei dem Zustände mit 

gleichen Kernen zusammengefaßt wurden, entspricht der Anzahl des LR(0)-Parsers. 

Ein solcher Parser heißt LALR(1)-Parser. 

109


S ′ 0 = { [S′ → .S, {$}], 

[S → .L=R, {$}], 

[S → .R, {$}], 

[L → .∗R, {=, $}], 

[L → .id, {=, $}], 

[R → .L, {=, $}]} 

S ′ 1 = { [S′ → S., {$}]} 

S ′ 2 

S ′ 3 

S ′ 4 

= { [S → L.=R, {$}], 

[R → L., {=, $}]} 

= { [S → R., {$}]} 

= { [L → ∗.R, {=, $}], 

[R → .L, {=, $}], 

[L → .∗R, {=, $}], 

[L → .id, {=, $}]} 

S ′ 5 

S ′ 6 

S ′ 7 

S ′ 8 

S ′ 9 

= { [L → id., {=, $}]} 

= { [S → L=.R, {$}], 

[R → .L, {=, $}], 

[L → .∗R, {=, $}], 

[L → .id, {=, $}]} 

= { [L → ∗R., {=, $}]} 

= { [R → L., {=, $}]} 

= { [S → L=R., {$}]} 


SLR(1)-Items für die Grammatik aus Beispiel 43. 

Bei der Vereinigung der Zustände ist zu beachten, daß durch diese Vereinigung neue 

Konflikte entstehen können. Daher ist diese Methode nicht auf alle LR(1)-Sprachen 

anwendbar, so daß nicht alle LR(1)-Sprachen durch LALR(1)-Parser akzeptiert werden 

können. 

Die Vorausschaumenge eines Items in einem Zustand kann auch direkt ohne die 

vorherige Konstruktion eines LR(1)-Parsers berechnet werden: 

LAL(q, [X → α.]) = {a ∈ VT | S ′ ⇒ βXaw und δ ∗ d(qd,βα) = q} 

Dabei ist δd die Übergangsfunktion des LR-DEA(G). In LAL(q, [X → α.]) sind also 

nur noch Terminalsymbole, die auf X in einer Rechtssatzform folgen können und die 

den charakteristischen endlichen Automaten LR-DEA(G) in den Zustand q bringen. 

Die Definition von LAL(q, [X → α.]) ist nicht konstruktiv, da in ihr i. allg. unendliche 

Mengen von Rechtssatzformen auftreten. Ein Verfahren zur effizienten der 

Vorausschaumengen für LALR(1)-Parser ist in [WM96] angegeben. 


Wir erzeugen einen LALR(1)-Automaten, indem wir die Zustände in Abbildung 3.21, 

deren Items dieselben Kerne besitzen, zu einem Zustand zusammenfassen und die zugehörigen 

Vorausschaumengen vereinigen (Abbildung 3.25). In Abbildung 3.20 ist S2 

der einzige ungeeigenete Zustand. Die Vorausschaumenge für das vollständige Item 

110

S ′′ 

0 = { [S′ → .S, {$}], 

[S → .L=R, {$}], 

[S → .R, {$}], 

[L → .∗R, {=, $}], 

[L → .id, {=, $}], 

[R → .L, {$}]} 

S ′′ 

1 = { [S′ → S., {$}]} 

S ′′ 

2 

S ′′ 

3 

S ′′ 

4 

= { [S → L.=R, {$}], 

[R → L., {$}]} 

= { [S → R., {$}]} 

= { [L → ∗.R, {=, $}], 

[R → .L, {=, $}], 

[L → .∗R, {=, $}], 

[L → .id, {=, $}]} 

S ′′ 

5 

S ′′ 

6 

S ′′ 

7 

S ′′ 

8 

S ′′ 

9 


= { [L → id., {=, $}]} 

= { [S → L=.R, {$}], 

[R → .L, {$}], 

[L → .∗R, {$}], 

[L → .id, {$}]} 

= { [L → ∗R., {=, $}]} 

= { [R → L., {=, $}]} 

= { [S → L=R., {$}]} 


LALR(1)-Items für die Grammatik aus Beispiel 43. 

in S ′′ 

2 ist {$}. Damit ist der Shift-Reduce-Konflikt aus S2 im Zustand S ′′ 

2 beseitigt. 

Da es keine weiteren ungeeigneten Zustände gibt, ist die Grammatik in Beispiel 43 

eine LALR(1)-Grammatik. Die Zustandsmenge des charakteristischen endlichen Automaten 

mit LALR(1)-Items ist in Abbildung 3.24 angegeben. 

Definition 45 

Eine kontextfreie Grammatik, für die das SLR- (LALR-) Verfahren keine ungeeigneten 

Zustände ergibt, nennen wir eine SLR- (LALR-) Grammatik. 

Das LALR(1)-Parseverfahren wird insbesondere in Parser-Generatoren wie z.B. yacc 

[MB92] verwendet. Diese Programme erzeugen für eine Eingabedatei, die eine Sprachbeschreibung 

in Form einer kontextfreien Grammatik (und eventuell zusätzliche Informationen) 

enthält, einen Parser, der die von der Grammatik beschriebene Sprache 

erkennt. Dieser Parser liegt oft in Form von Quelltext vor, so daß er in Programme 

integriert werden kann (yacc erzeugt Parser in der Sprache C [KR90]). Das LALR- 

Verfahren eignet sich besonders für Parser-Generatoren, da die Zustandsmenge des 

zugehörigen Automaten effizient berechenbar ist. 

Für weitere Informationen zu SLR- und LALR-Parsern verweisen wir auf [WM96] 

und [ASU99]. 

111


S 

I I 

0 1 

L = 

R 

I I I 

id 

R 

* 

I 

R 

I I 

id 

I 

3 

2 6 9 

4 7 

5 

* 

L 

I 8 

* 

L 

id 

I 

L 

I I 

11 

R 

id 

Abbildung 3.25: Charakteristischer endlicher LR(1)-Automat zur Grammatik aus 

Beispiel 43. 

112 

I 

10 

12 

* 

13

3.4.2 Fehlerbehandlung bei der Bottom-Up-Analyse 


Ein LR(k)-Parser erkennt einen Fehler, sobald er in der action-Tabelle auf einen Fehlereintrag 

trifft (nicht beim Nachsehen in der goto-Tabelle). Bei einer LR(1)-Analyse 

führt der Parser zwischen Vorliegen und Erkennen eines Fehlers keine weiteren Reduktionen 

durch, während die SLR(1)- und LALR(1)-Parser eventuell noch Reduktionen 

vornehmen (aufgrund der weniger differenzierten Vorausschaumengen). Bei 

allen Verfahren werden aber zwischen dem Vorliegen eines Fehlers und dem Erkennen 

der Fehlersituation durch den Parser keine Shift-Schritte mehr ausgeführt. 

Wie bei der Fehlerbehandlung der Top-Down-Analyse stehen mehrere Verfahren zur 

Auswahl. 

Panic recovery: Das Verfahren der panic recovery überliest beim Auftreten eines 

Fehlers einen Teil der Eingabe bis zu einem synchronisierenden Symbol. 

Zuerst wird der Keller von oben her durchsucht, bis ein Zustand s gefunden wird, 

zu dem es für ein Nichtterminal A einen Eintrag in der goto-Tabelle gibt. Es wird 

geprüft, ob die Verwendung dieses Eintrags eine Aktion des Parsers ermöglichen wird. 

Ist dies der Fall, wird der Keller bis zu diesem Zustand gelöscht (s selbst wird nicht 

entfernt) und goto[s,A] auf den Keller gelegt. Dann wird die Eingabe bis zu einem 

Symbol aus FOLLOW(A) gelöscht. Auf diese Weise täuscht der Parser vor, daß der 

zu A gehörende Teil der Eingabe erfolgreich analysiert wurde und daher die Analyse 

fortgesetzt werden kann. Auf die weiteren Verfahren zur Fehlerbehandlung gehen wir 

an dieser Stelle nicht ein und verweisen auf [WM96] und [ASU99]. 


Gegeben sei die Grammatik G zur Erzeugung arithmetischer Ausdrücke. 

S → E (1) 

E → E + T (2) 

E → T (3) 

T → T ∗ F (3) 

T → F (3) 

F → (E) (3) 

F → id (7) 

Wir wollen untersuchen, welche Aktionen ein LR-Parser mit Panic-Recovery-Strategie 

für G bei der Eingabe des fehlerhaften Wortes ”id+(∗id))+id” durchführt. 

Die Zustände: 

113


I0 : S → .E ,{$} 

E → .E + T ,{$, +} 

E → .T ,{$, +} 

T → .T ∗ F .{$, *, +} 

T → .F .{$, *, +} 

F → .id .{$, *, +} 

F → .(E) .{$, *, +} 

I1 : S → E. ,{$} 

E → E. + T ,{$, +} 

I2 : F → id. .{$, *, +} 

I3 : T → F. .{$, *, +} 

I4 : F → (.E) .{$, *, +} 

E → .E + T ,{), +} 

E → .T ,{), +} 

T → .T ∗ F .{), *, +} 

T → .F .{), *, +} 

F → .id .{), *, +} 

F → .(E) .{), *, +} 

I5 : E → E + .T ,{$, +} 

T → .T ∗ F .{$, *, +} 

T → .F .{$, *, +} 

F → .id .{$, *, +} 

F → .(E) .{$, *, +} 

I6 : F → (E.) .{$, *, +} 

E → E. + T ,{), +} 

I7 : E → E + T. ,{$, +} 

T → T. ∗ F .{$, *, +} 

I8 : T → T ∗ .F .{$, *, +} 

F → .id .{$, *, +} 

F → .(E) .{$, *, +} 

I9 : T → T ∗ F. .{$, *, +} 

I10 : E → T. ,{$, +} 

T → T. ∗ F .{$, *, +} 

I11 : F → (E). .{$, *, +} 

114 

I ′ 2 : F → id. .{), *, +} 

I ′ 3 : T → F. .{), *, +} 

I ′ 4 : F → (.E) .{), *, +} 

E → .E + T ,{), +} 

E → .T ,{), +} 

T → .T ∗ F .{), *, +} 

T → .F .{), *, +} 

F → .id .{), *, +} 

F → .(E) .{), *, +} 

I ′ 5 : E → E + .T ,{), +} 

T → .T ∗ F .{), *, +} 

T → .F .{), *, +} 

F → .id .{), *, +} 

F → .(E) .{), *, +} 

I ′ 6 : F → (E.) .{), *, +} 

E → E. + T ,{), +} 

I ′ 7 : E → E + T. ,{), +} 

T → T. ∗ F .{), *, +} 

I ′ 8 : T → T ∗ .F .{), *, +} 

F → .id .{), *, +} 

F → .(E) .{), *, +} 

I ′ 9 : T → T ∗ F. .{), *, +} 

I ′ 10 : E → T. ,{), +} 

T → T. ∗ F .{), *, +} 

I ′ 11 : F → (E). .{), *, +}


action goto 

Zustand + * id ( ) $ + * id ( ) S E T F 

I0 sync sync s s sync sync I2 I4 I1 I10 I3 

I1 s acc I5 

I2 r7 r7 r7 

I3 r5 r5 r5 

I4 sync sync s s sync sync I ′ 2 I ′ 4 I6 I ′ 10 I ′ 3 

I5 sync sync s s sync sync I2 I4 I7 I3 

I6 s s I5 I11 

I7 r2 s r2 I8 

I8 sync sync s s sync sync I2 I4 I9 

I9 r4 r4 r4 

I10 r3 s r3 I8 

I11 r6 r6 r6 

I ′ 2 r7 r7 r7 

I ′ 3 r5 r5 r5 

I ′ 4 sync sync s s sync sync I ′ 2 I ′ 4 I ′ 6 I ′ 10 I ′ 3 

I ′ 5 sync sync s s sync sync I ′ 2 I ′ 4 I ′ 7 I ′ 3 

I ′ 6 s s I ′ 5 I11 ′ 

I ′ 7 r2 s r2 I ′ 8 

I ′ 8 sync sync s s sync sync I ′ 2 I ′ 4 I ′ 9 

I ′ 9 r4 r4 r4 

I ′ 10 r3 s r3 I ′ 8 

I ′ 11 r6 r6 r6 

FOLLOW(S)= {$} 

FOLLOW(E)= {$, +, )} 

FOLLOW(T)= {$, +, ), *} 

FOLLOW(F)= {$, +, ), *} 

rX reduce nach Regel X 

s shift 

sync synchronisierendes Symbol für F 

acc akzeptieren 

Fehler 1: Keine Aktion möglich, aber zu dem Zustand 4 gibt es einen Sprungeintrag 

goto(I4,F) = I ′ 3. Die Eingabe wird bis zu dem synchronisierenden Symbol gelöscht 

(hier wird nichts gelöscht, da ∗ ∈ FOLLOW(F)). Es wird I ′ 3 auf den Stack gelegt. 

Fehler 2: Zu I8 gibt es einen Sprungeintrag zu I9 mit F. Dieser erlaubt jedoch keine 

weitere Aktion (action(I9, ′ ) ′ ) = ǫ). Deshalb wird stattdessen ) überlesen. 

115


Fehler 3: Da es einen Sprungeintrag gibt, kann synchronisiert werden. Das synchronisierende 

Symbol ist ’+’. 

Eingabe Keller Aktion 

id+(*id))+id$ I0 ǫ 

+(*id))+id$ I2I0 F → id 

F+(*id))+id$ I0 ǫ 

+(*id))+id$ I3I0 T → F 

T+(*id))+id$ I0 ǫ 

+(*id))+id$ I10I0 E → T 

E+(*id))+id$ I0 ǫ 

+(*id))+id$ I1I0 ǫ 

(*id))+id$ I5I1I0 ǫ 

*id))+id$ I4I5I1I0 sync = Fehler 1 

*id))+id$ I ′ 3I4I5I1I0 T → F 

T*id))+id$ I4I5I1I0 ǫ 

*id))+id$ I ′ 10I4I5I1I0 ǫ 

id))+id$ I ′ 8I ′ 10I4I5I1I0 ǫ 

))+id$ I ′ 2I ′ 8I ′ 10I4I5I1I0 F → id 

F))+id$ I ′ 8I ′ 10I4I5I1I0 ǫ 

))+id$ I ′ 9I ′ 2I ′ 8I ′ 10I4I5I1I0 T → T ∗ F 

T))+id$ I4I5I1I0 ǫ 

))+id$ I ′ 10I4I5I1I0 E → T 

E))+id$ I4I5I1I0 ǫ 

))+id$ I6I4I5I1I0 ǫ 

)+id$ I8I6I4I5I1I0 sync = Fehler 2, Überlesen 

+id$ I8I6I4I5I1I0 sync = Fehler 3 

+id$ I9I6I4I5I1I0 T → T ∗ F 

T+id$ I5I1I0 ǫ 

+id$ I7I5I1I0 E → E + T 

E+id$ I0 ǫ 

+id$ I1I0 ǫ 

id$ I5I1I0 ǫ 

$ I2I5I1I0 F → id 

F$ I5I1I0 ǫ 

$ I3I5I1I0 T → F 

T$ I5I1I0 ǫ 

$ I7I5I1I0 E → E + T 

E$ I0 ǫ 

$ I1I0 acc 

In [ASU99], Band 1, S. 311–313, befindet sich eine ähnliche Grammatik, in der für 

116

jede fehlerhafte Aktion eine Fehlerroutine aufgerufen wird. 

3.5 Parser Generatoren 

3.5 Parser Generatoren 

Parser Generatoren dienen der automatischen Generierung eines Parsers für eine 

entsprechende Sprachspezifikation. Die Spezifikation wird in Form einer Grammatik 

(BNF, EBNF, ...) in einer generatorspeizifischen Sprache hinterlegt. Als Ausgabe 

erzeugt der Generator ein Programm, das einen Parser für diese Sprache in einer 

vorher angegeben Programmiersprache implementiert. Der Umfang der möglichen 

Zielsprachen ist abhängig vom jeweiligen Generator. Häufig ist der Parser Generator 

auch Teil eines Compiler-Generators (Compiler-Compiler) wobei in verschiedenen 

Implementationen gelegentlich eine Trennung zwischen Scanner-Generator (Lexer) 

und Parser-Generator (intern oder extern) vorgenommen wird. Hinzu kommt meistens 

auch noch ein Tree Parser der zur Verarbeitung des konstruierten Syntaxbaums 

dient. 

Die Vorteile solcher Systeme sind die Nachweisbarkeit der Korrektheit des generierten 

Compilers und das Einsparen aufwendiger und fehleranfälliger Programmierarbeit. 

Einige Beispiele für Generatoren sind: 

• Lex/Yacc [JL92][LYP] 

• ANTLR [ANT] 

• JavaCC [JAV] 

• Coco/R [HM] 

• SableCC [SAB] 

117

4 Semantische Analyse 

In der abschließenden Analysephase des Compilers wird, nach der Überprüfung der 

lexikalischen und syntaktischen Struktur des zu übersetzenden Quelltextes, die statische 

Semantik des Programmes untersucht. 

Man bezeichnet eine (nicht kontextfreie) Eigenschaft eines Konstrukts einer Programmiersprache 

als eine statische semantische Eigenschaft, wenn 

1. für jedes Vorkommen dieses Konstrukts in einem Programm der “Wert” dieser 

Eigenschaft für alle (dynamischen) Ausführungen des Konstrukts gilt, 

2. für jedes Vorkommen des Konstrukts in einem konkreten Programm diese Eigenschaft 

berechnet werden kann. 

Beispiele für statische semantische Eigenschaften sind 

• Definiertheit, Sichtbarkeit und Gültigkeit: hierbei wird überprüft, ob die im Programm 

verwendeten Bezeichner (z.B. Variablennamen und Namen von Unterprogrammen) 

zuvor deklariert wurden. Wird ein Bezeichner mehrfach in einem 

Programm deklariert (z.B. in verschiedenen Unterprogrammen), muß bei einem 

Auftreten eines Bezeichners die aktuell gültige Deklaration zugeordnet werden 

können. 

Die Überprüfung dieser Eigenschaften ist mit dem Ansatz der kontextfreien 

Grammatiken nicht durchführbar. Zum Beispiel läßt sich die Deklaration eines 

Bezeichners w und dessen Verwendung im folgenden Programmtext auf die 

Sprache {wcw | w ∈ (a|b) ∗ } zurückführen, die mit kontextfreien Grammatiken 

nicht erzeugt werden kann (siehe [Sch08]). 

• Typisierung: Den Werten, Variablen und Unterprogrammen eines Programms 

werden in den meisten Programmiersprachen Typen zugeordnet. Typen sind 

Wertemengen wie z.B. boolesche Werte, ganze Zahlen, Fließkommazahlen und 

Zeichen. Zur semantischen Analyse gehört die Überprüfung auf korrekte Typisierung 

eines Programms. In “stark getypten” Programmiersprachen ist der 

Typ jedes Ausdrucks zur Übersetzungszeit bestimmbar. 

Weiterhin umfaßt die Überprüfung der Semantik 

118 

• Überprüfungen auf Eindeutigkeit (z.B. darf innerhalb einer case-Anweisung 

nicht zweimal dasselbe Label auftreten), 

• auf Namen bezogene Überprüfungen (z.B. muß in Ada [Bar83] der Name eines 

Blockes am Anfang und am Ende des Blockes auftreten).

E 

E + E 

integer 

real 

real 

4.1 Attributierte Grammatiken 

Abbildung 4.1: Beispiel eines attributierten Strukturbaums. 

Wir werden bei der Beschreibung der semantischen Analyse vor allem auf die Typüberprüfungen 

eingehen. 


Als theoretisches Hilfsmittel für die semantische Analyse verwenden wir attributierte 

Grammatiken. Dabei wird der von der Syntaxanalyse erzeugte Strukturbaum, der 

die syntaktische Struktur des zu analysierenden Programmtextes darstellt, durch Zusatzinformationen 

ergänzt, die die Überprüfung der statischen semantischen Eigenschaften 

ermöglichen. Wir erhalten einen sogenannten attributierten Strukturbaum. 

Beispiel 46 

In Abbildung 4.1 ist ein Ausschnitt aus einem Strukturbaum angegeben, der die Anwendung 

eines Additionsoperators auf zwei Teilausdrücke beschreibt. Den Nichtterminalen 

E sind Attribute zugeordnet, die den Typ des Ausdrucks, für den das jeweilige 

Nichtterminal steht, angeben. Das Attribut Typ ist für alle Auftreten des Nichtterminals 

E definiert, aber jedes Auftreten von E besitzt einen eigenen Attributwert. 

Der Typ des linken Teilbaums ist integer, der des rechten Teilbaums ist real. Die 

semantische Analyse kann aus diesen Informationen ermitteln, daß der Typ des Gesamtausdrucks 

real 1 sein muß und ordnet der Wurzel des Baums den Attributwert 

real zu. 

Den Grammatiksymbolen werden also zusätzliche Plätze (Attribute) zur Aufnahme 

von Informationen zugeordnet. 

Die Berechnung der Attributwerte im attributierten Strukturbaum wird dabei durch 

semantische Regeln definiert. Jeder Produktion der Grammatik werden semantische 

Regeln zugeordnet, die beschreiben, wie die Attributwerte der in der Produktion 

vorkommenden Symbole berechnet werden. 

Wir unterscheiden folgende Begriffe: 

1 Andernfalls würden bei der Addition eventuelle Nachkommastellen verloren gehen 

119


Abbildung 4.2: Synthetische und inherite Attribute. 

• Attribute sind Grammatiksymbolen zugeordnete Plätze, 

• Attributvorkommen entsprechen dem Vorkommen der zugehörigen Grammatiksymbole 

in Produktionen, 

• Attributexemplare sind die konkreten Auftreten von Attributen in einem Strukturbaum 

(ihnen werden die Attributwerte zugeordnet). 

Wir unterscheiden zwei Arten von Attributen: 

• synthetische Attribute: die Werte dieser Attribute werden im Strukturbaum 

bottom-up, also von den Blättern ausgehend zur Wurzel hin, berechnet (siehe 

den linken Baum in Abbildung 4.2), 

• inherite Attribute: die Werte dieser Attribute werden im Strukturbaum topdown, 

also von der Wurzel ausgehend zu den Blättern hin, berechnet, wobei 

hier jeweils auch Werte von Geschwisterknoten verwendet werden dürfen (siehe 

den rechten Baum in Abbildung 4.2). 

Durch die Kombination von synthetischen und inheriten Attributen ist ein Informationstransfer 

zwischen Teilbäumen möglich. 

Beispiel 47 

Wir nehmen an, daß ein Programm (Nichtterminal P) aus einem Deklarationsblock 

(Nichtterminal D) und einem Anweisungsteil (Nichtterminal S) besteht, die durch 

ein Semikolon voneinander getrennt sind (die Produktion lautet also P → D;S). 

Im Deklarationsteil werden die Typen der Bezeichner, die im Anweisungsteil verwendet 

werden, deklariert. Innerhalb des Strukturbaums, der den Deklarationsblock 

beschreibt, werden die Typen der einzelnen Bezeichner durch synthetische Attribute 

“gesammelt” (siehe Abbildung 4.3). Im Anweisungsteil werden diese Typinformationen 

benötigt, daher werden sie als inherite Attribute bei der Analyse des Anweisungsteils 

miteinbezogen. 

Wir erläutern nun zunächst die Konzepte der attributierten Grammatiken anhand 

eines Beispiels. Wir betrachten eine kontextfreie Grammatik, die rationale Zahlen 

in Form von Binärziffern definiert. Durch die Angabe semantischer Regeln wird die 

Berechnung des Werts einer rationalen Zahl ermöglicht. 

120

P 

D ; S 


Abbildung 4.3: Berechnung von Typinformationen im Strukturbaum. 

Beispiel 48 (Binärzahlen) 

Wir betrachten die folgende kontextfreie Grammatik zur Beschreibung von rationalen 

Zahlen im Binärformat (N ist Startsymbol) [KV97]: 

N → L | L . L 

L → B | L B 

B → 0 | 1 

Wir geben nun semantische Regeln an, die eine Attributierung zur Berechnung des 

Zahlwerts der Binärzahlen erlauben. 

Jedes Nichtterminalsymbol erhält ein Attribut v zur Aufnahme von rationalen Zahlen: 

B.v, N.v, L.v. Weiterhin benötigen wir ein Hilfsattribut l zur Aufnahme der Anzahl 

der Ziffern nach dem Dezimalpunkt: L.l. 

Tritt ein Nichtterminal in einer Produktion mehrfach auf, müssen wir die zugehörigen 

Attributvorkommen unterscheiden. So ergibt sich N.v in der Produktion N → L.L aus 

L1.v und L2.v. Generell gilt, daß bei mehrfachem Vorkommen eines Nichtterminals 

das linkeste dieser Vorkommen den Index 1 erhält (die linke Seite der Produktion 

wird miteinbezogen). 

Wir beschreiben die Berechung des Zahlwertes mit folgenden den Produktionen der 

Grammatik zugeordneten semantischen Regeln: 

B → 0 B.v := 0 

B → 1 B.v := 1 

L → B L.v := B.v 

L.l := 1 

L → LB L1.v := 2 ∗ L2.v + B.v 

L1.l := L2.l + 1 

N → L N.v := L.v 

N → L.L N.v := L1.v + L2.v/2 L2.l 

In Abbildung 4.4 ist der attributierte Strukturbaum für die Ableitung des Wortes 

1101.01 angegeben. Als Zahlwert für die Binärzahl 1101.01 ergibt sich 13.25. 

Die Berechnung erfolgt bottom-up, da nur synthetische Attribute verwendet werden, 

121


d.h. die Werte der Attribute auf der linken Seite der jeweiligen Produktion hängen 

nur von den Werten der Attribute auf der rechten Seite der Produktion ab. 

Unter Verwendung eines inheriten Attributs läßt sich eine andere Variante angeben. 

Wir verwenden das zusätzliche Attribut s (“Stelle”), das die Stelligkeit einer 

Binärziffer angibt. Die semantischen Regeln lauten: 

B → 0 B.v := 0 

B → 1 B.v := 2 B.s 

L → B L.v := B.v 

L.l := 1 

B.s := L.s 

L → LB L1.v := L2.v + B.v 

L1.l := L2.l + 1 

L2.s := L1.s + 1 

B.s := L1.s 

N → L N.v := L.v 

L.s := 0 

N → L.L N.v := L1.v + L2.v 

L1.s := 0 

L2.s := −L2.l 

Die Ableitung des Wortes 1101.01 ist in Abbildung 4.5 dargestellt. Das Attribut s 

ist ein inherites Attribut, das zu Beginn der Analyse an der Wurzel des linken Teilbaums 

auf 0 gesetzt und dann im Baum an die jeweiligen Kinder der Knoten weitergereicht 

wird. Der Wert für s an der Wurzel des rechten Teilbaums ergibt sich aus 

dem synthetischen Attribut l, das die Länge der im Teilbaum dargestellten Ziffernfolge 

repräsentiert. Bei der Auswertung werden also sowohl synthetische (v,l) als auch 

inherite Attribute (s) verwendet. 

Werden die Werte 0 und 1 im Strukturbaum durch ein Terminal num repräsentiert, 

kann num ein synthetisches Attribut für die jeweiligen Werte erhalten. Statt 

berechnet zu werden, wird der Attributwert für num dann entsprechend durch einen 

”Scanner” 2 geliefert. So kann die Berechnung für verschiedene Eingaben durchgeführt 

werden. 

Wir geben nun die formale Definition einer attributierten Grammatik an. 

Definition 46 

Ein Tupel (G,A,R) ist eine attributierte Grammatik genau dann, wenn 

• G kontextfreie Grammatik, 

• A = � 

A(X) Menge der Attribute (A endlich) und 

X∈VN ∪VT 

2 im Übersetzungsfall durch den Scanner des Compilers 

122

v:3 

l:2 

L 

B 

1 

L 

v:1 

l:1 

v:1 

v:6 

l:3 

v:13 

l:4 

L 

N 

L . 

L 

B 0 

v:1 

1 

B 

v:0 

1 

B v:1 

v:13.25 


Abbildung 4.4: Attributierter Strukturbaum zur Analyse einer Binärzahl. 

L 

B 

0 

v:0 

l:1 

v:0 

v:1 

l:2 

B 

1 

v:1 

123


s:2 

v:12 

l:2 

L 

B 

1 

s:1 

v:12 

l:3 

L 

s:3 

v:8 

l:1 

s:3 

v:8 

s:0 

v:13 

l:4 

L 

s:2 

v:4 

B 

N 

L . 

L 

s:1 

v:0 

1 

s:0 

v:1 

B 

0 

B 

1 

v:13.25 

s:-1 

v:0 

l:1 

s:-1 

v:0 

L 

B 

0 

s:-2 

v:0.25 

l:2 

B 

1 

s:-2 

v:0.25 

Abbildung 4.5: Attributierter Strukturbaum zur Analyse einer Binärzahl mit inheritem 

Attribut. 

124

• R = � 

p∈P R(p) die Menge der semantischen Regeln der Form 

Xi.a := f(Xi1.b1,...,Xik.bk) 


mit Xi,Xi1,...,Xik ∈ {X0,...,Xn}, bj ∈ A(Xij) für die Produktion X0 → 

X1...Xn ist und wenn 

• für jedes Auftreten eines Grammatiksymbols X in einem Strukturbaum für ein 

w ∈ L(G) und für jedes a ∈ A(X) höchstens eine Regel in R zur Berechnung 

von X.a anwendbar ist. 

Die vierte Bedingung fordert, daß eine attributierte Grammatik eindeutig ist. Daher 

darf bei der Auswahl der anzuwendenden semantischen Regel kein Nichtdeterminismus 

entstehen. Aus diesem Grund kann ein Attribut nicht zugleich synthetisch und 

inherit sein, da dann eine solche Auswahl zwischen zwei möglichen Regeln (einer für 

die synthetische und einer für die inherite Berechnung des Attributwerts) getroffen 

werden müßte und somit die Eindeutigkeit verletzt wäre. 

Neben den semantischen Regeln werden zu Produktionen P manchmal semantische 

Bedingungen der Form B(Xi.a,...,Xj.b) angegeben. Dabei ist B ein Prädikat, das 

Aussagen über die Werte von Attributvorkommen Xi.a, ..., Xj.b in P macht. Semantische 

Bedingungen liefern Informationen über Korrektheit bzgl. der statischen 

Semantik des bis dahin überprüften Teilbaums. 

Definition 47 

Sei p Produktion. Die Menge der definierenden Vorkommen von Attributen für p ist 

AF(p) = {Xi.a | Xi.a := f(...) ∈ R(p)}. 

Ein Attribut X.a heißt synthetisch genau dann, wenn ∃p : X → α mit X.a ∈ AF(p). 

Ein Attribut X.a heißt inherit genau dann, wenn ∃p : Y → αXβ mit X.a ∈ AF(p). 

AS(X) sei die Menge der synthetischen Attribute von X, AI(X) die Menge der 

inheriten Attribute von X. 

Die Menge der definierenden Vorkommen einer Produktion p sind die Attributvorkommen, 

denen durch eine semantische Regel zu p ein Wert zugewiesen wird. Ein 

Attribut X.a heißt synthetisch, wenn definierende Vorkommen von X nur in Produktionen 

auftreten, bei denen X auf der linken Seite vorkommt. Entsprechend ist 

für ein inherites Attribut Y.b gefordert, daß alle definierenden Vorkommen nur bei 

Produktionen auftreten, bei denen Y auf der rechten Seite vorkommt. 

Wir beschreiben nun informell die Semantik einer attributierten Grammatik. 

Semantik einer attributierten Grammatik 

Unter bestimmten Bedingungen wird für jeden Strukturbaum t der zugrundeliegenden 

kontextfreien Grammatik eine Zuordnung zu den Knoten von t festgelegt. 

125


Z.c 

Y.b 

Abbildung 4.6: Darstellung der direkten Abhängigkeiten zwischen 

Attributvorkommen. 

Sei t ein Strukturbaum einer attributierten Grammatik, sei n ein Knoten in t und 

sei n mit X beschriftet. 

Für jedes Attribut a ∈ A(X) liegt an n ein Attributexemplar an vor. Dieses entspricht 

einem Attributvorkommen zu der an dieser Stelle im Strukturbaum angewandten 

Produktion (zur Erzeugung von n und seinen eventuellen Nachfolgern). Nach Definition 

46 gibt es dann höchstens eine dieser Produktion zugeordnete semantische Regel 

zur Berechnung von an. 

Da einer Produktion der Grammatik mehrere semantische Regeln zugeordnet sein 

können, zwischen denen Abhängigkeiten bestehen können, muß zur Berechnung der 

Attributwerte eine geeignete Strategie entwickelt werden. 

In einer Produktion einer Grammatik mit der semantischen Regel X.a := f(Z.c,Y.b) 

müssen Z.c und Y.b bekannt sein, wenn X.a berechnet wird. Diese Abhängigkeiten 

zwischen Attributvorkommen lassen sich mit gerichteten Graphen wie in Abbildung 

4.6 beschreiben. 

Definition 48 

Sei p : X0 → X1...Xn Produktion. Wir ordnen p den Graphen der direkten Abhängigkeiten 

DA(p) := {(Xi.a,Xj.b) | Xj.b := f(...,Xi.a,...) ∈ R(p)} zu. 

Eine Kante (Xi.a,Xj.b) ∈ DA(p) besagt, daß bei Anwendung der Produktion p der 

Wert von Xi.a bekannt sein muß, damit Xj.b berechnet werden kann. 

Die indirekten Abhängigkeiten zwischen Attributvorkommen erhält man durch Bildung 

der transitiven Hülle des Abhängigkeitsgraphen. 


In Abbildung 4.7 ist der Graph der direkten Abhängigkeiten für die Produktion L → 

LB mit der zweiten Variante semantischer Regeln aus Beispiel 48 angegeben. 

Die Abhängigkeitsgraphen der einzelnen Produktionen können auch miteinander 

“verklebt” werden, so daß ein gemeinsamer Abhängigkeitsgraph für alle Attributvorkommen 

eines Ableitungsbaums entsteht. In Abbildung 4.8 ist dieser “verklebte” 

Graph für die Ableitung aus Beispiel 48 angegeben. 

126 

X.a

L2.v 

B.v 

L2.l 

L1.s 

❍ ❍❍❍ 

✦ ✦✦✦✦ 

✟ ✟✟✟ 

❍ ❍❍❍ 

L1.v 

L1.l 

L2.s 

B.s 

Abbildung 4.7: Beispiel eines Abhängigkeitsgraphen. 

v s l 

L 

v s 

v s l 

L 

v s 

L 

B 

1 

N 

L . v s l L 

B 

v s l B v s 0 

v s 

v s l 

1 

B 

1 


v s l L B v s 

v s 

Abbildung 4.8: “Verklebter” Abhängigkeitsgraph. 

v 

B 

0 

1 

127


Ein Abhängigkeitsgraph für einen Ableitungsbaum darf keinen Zyklus enthalten, da 

die Attribute dann nicht auswertbar sind. Daher ist der Graph auf eventuelle Zirkularität 

zu überprüfen. 

Außerdem müssen zur Berechnung der Attribute “genügend” Regeln existieren. 

Definition 49 

Eine attributierte Grammatik ist vollständig genau dann, wenn für alle Produktionen 

p gilt: 

Wenn p : X → α, dann AS(X) ⊆ AF(p), wenn p : Y → αXβ, dann AI(X) ⊆ 

AF(p). Weiterhin muß gelten AS(X) ∪ AI(X) = A(X). 

Jede vollständige und nicht-zirkuläre attributierte Grammatik G ist für jeden Ableitungsbaum 

von G auswertbar. 

Eine Möglichkeit der Auswertung der Attributvorkommen ist, für jedes Attributvorkommen 

einen eigenen Prozeß zu generieren. Alle Prozesse laufen parallel. Ein 

einzelner Prozeß berechnet den Wert des zugehörigen Attributvorkommens, sobald 

alle dafür notwendigen Daten verfügbar sind. Dieses Auswertungsverfahren ist im 

allgemeinen zu aufwendig (in bezug auf Zeit und Speicherplatz). Effizientere Auswertungsstrategien 

werden in [ASU99] beschrieben. 

Die Auswertung ist für spezielle Klassen attributierter Grammatiken einfacher. Treten 

z.B. nur synthetische Attribute auf, kann ein Bottom-Up-Parser ohne Probleme 

die Attribute mit berechnen. Aus diesem Grund sollte die gewählte Auswertungsstrategie 

möglichst im Einklang mit der Parsemethode gewählt werden. 

Beim Übersetzerbau können die semantischen Regeln Funktionen mit Seiteneffekten 

beinhalten (teilweise ohne tatsächliche Berechnung von Attributwerten). So ist 

es im allgemeinen notwendig, während der semantischen Analyse Typinformationen 

in die Symboltabelle einzufügen. Dabei werden z.B. den Bezeichnern, die der Scanner 

(bzw. der Sieber) in der lexikalischen Analyse in die Symboltabelle eingetragen 

hat, Typinformationen zugeordnet. Treten die Bezeichner im Anweisungsteil eines 

Programms auf, werden diese Typinformationen aus der Tabelle gelesen und für die 

Typüberprüfung verwendet. 

4.2 Typüberprüfung 

Die Typüberprüfung verifiziert, daß der Typ eines Konstrukts mit dem Typ “zusammenpaßt”, 

der aufgrund des Kontextes erwartet wird. 

Beispiele: 

128 

• die Operation mod erwartet integer-Operanden, 

• Dereferenzierung kann nur auf Zeiger angewendet werden,

• Indizieren ist nur bei Arrays erlaubt. 


Ein wichtiges Teilproblem bei der Typüberprüfung ist die Frage, wann Typen “zusammenpassen”. 

Typen sollen nicht nur auf Gleichheit, sondern auch auf Möglichkeiten 

zur Typkonversion hin überprüft werden. Zum Beispiel ist in vielen Sprachen eine 

Typkonversion von integer nach real möglich. So ist zum Beispiel für die Konstante 

1 im Ausdruck 1 + 1.5 eine Umwandlung des Typs integer nach real notwendig. 

Typinformationen werden auch bei der Codegenerierung benötigt. Zum Beispiel ist in 

den meisten Sprachen die Überladung des Operators + möglich, d.h. es wird dasselbe 

Operatorsymbol für die Addition von integer-Zahlen und für die Addition von real- 

Zahlen verwendet. Der Codegenerator muß anhand der Typinformation entscheiden, 

für welche Art von Addition er Code erzeugen soll. 

Einige Sprachen (vor allem aus der Familie der funktionalen Sprachen) erlauben 

Polymorphie [Thi97]. Eine Funktion ist polymorph, wenn sie auf Argumente unterschiedlichen 

Typs angewendet werden kann (die oben erwähnte +-Operation könnte 

man also auch als eine polymorphe Funktion auffassen). So ist zum Beispiel für eine 

Funktion zur Berechnung der Länge einer Liste der Typ der Listenelemente irrelevant. 

Andererseits möchte man nicht für jeden Listentyp (Zeichenliste, Zahlenliste 

usw.) eine eigene Funktion zur Längenberechnung definieren. Die Definition einer 

polymorphen Funktion ist daher für diese Aufgabe prädestiniert. 

4.2.1 Typsysteme 

Typsysteme enthalten Informationen über Typen in Programmiersprachen. Typinformationen 

in Programmiersprachen sind z.B. 

• in Pascal: “Wenn beide Operanden der arithmetischen Operatoren Addition, 

Subtraktion und Multiplikation vom Typ integer sind, dann ist das Ergebnis 

ebenfalls vom Typ integer.”, 

• in C: “Das Ergebnis des einstelligen Operators & ist ein Zeiger auf das Objekt, 

das durch den Operanden übergeben wurde. Wenn der Typ des Operanden t 

ist, dann ist ’Zeiger auf t’ der Typ des Ergebnisses.”. 

Das erste Beispiel zeigt, daß Ausdrücken ein Typ zugeordnet wird. Das zweite Beispiel 

zeigt, daß Typen eine Struktur haben, das heißt, daß man neue Typen aus gegebenen 

Typen konstruieren kann. 

Ein Typsystem umfaßt 

• Einfache Typen wie integer, boolean, character und real. Hierzu gehören auch 

Teilbereichstypen (z.B. (1..10)) und Aufzählungstypen 

(z.B. (rot,gelb,grün)). 

• Zusammengesetzte Typen wie Arrays, Records, Sets, Zeigertypen und Funktionstypen. 

129


Der Typ von Sprachkonstrukten wird durch Typausdrücke angegeben. 

Definition 50 

Ein Typausdruck ist 

• ein einfacher Typ 

oder 

• von der Form k(T1,...,Tn), wobei k ein Typkonstruktor und 

T1,...,Tn Typausdrücke sind. 

Die Menge der einfachen Typen und der Typkonstruktoren hängt von der betrachteten 

Sprache ab. Zusammengesetzte Typen werden mit Hilfe der Typkonstruktoren 

gebildet. 

Beispiel 50 

Wir betrachten Beispiele für einfache Typen und Typkonstruktoren: 

130 

• Beispiele für einfache Typen: boolean, char, integer, real, type error (zeigt Typfehler 

an) 

• Beispiele für Typkonstruktoren: 

– Arrays: Sei T Typausdruck. array(I,T) ist ein Typausdruck, der den Typ 

von Arrays mit Elementen vom Typ T und Indexmenge I bezeichnet (eigentlich 

müßte für jede Indexmenge ein eigener Typkonstruktor arrayI(T) 

verwendet werden). Zum Beispiel wird nach Bearbeitung von “var A: array 

[1..10] of integer” mit A der Typausdruck array(1..10,integer) assoziiert. 

– Records: Seien T1,...,Tm Typen, n1,...,nm Komponentennamen. Dann ist 

record((n1×T1)×...×(nm×Tm)) Typausdruck (eigentlich sind die n1,...,nm 

wieder Teil des Typkonstruktors). Zum Beispiel wird für den Programmtext 

type row = record 

address : integer; 

lexeme : array [1..15] of char 

end; 

var table : array [1..101] of row 

der Typ 

T1 = record((address × integer) × (lexeme × array(1..15,char)), 

der dem Typ von row entspricht, und der Typ T2 = array(1..101,T1) von 

table erzeugt.


– Zeigertypen: Sei T Typausdruck. Dann ist pointer(T) Typausdruck. Wird 

im Beispiel für Record-Typen die Zeile “var p: ↑row” hinzugefügt, ist der 

Typ von p pointer(T1). 

Ein Typsystem ist nun eine Sammlung von Regeln zur Zuweisung von Typausdrücken 

zu Teilen eines Programms. 

Ein Typüberprüfer ist die Implementierung eines Typsystems in Form eines Programms. 

Dieses Programm ist in der Regel ein Teilprogramm der semantischen Analyse. 

Typsysteme sind manchmal nicht nur sprach-, sondern auch compilerspezifisch. Zum 

Beispiel schließt in Pascal der Typ eines Arrays die Indexmenge mit ein. Einige 

Compiler erlauben jedoch, Prozeduren zu deklarieren, die als Parameter Arrays ohne 

Betrachtung der konkreten Indexmenge erhalten 3 . Diese Compiler verwenden daher 

ihr eigenes Typsystem. 

Statische und dynamische Überprüfung von Typen 

Wir unterscheiden zwischen der statischen und der dynamischen Typüberprüfung. 

Die statische Typüberprüfung umfaßt alle Typuntersuchungen, die während der Übersetzungszeit 

eines Programms durch den Compiler in der semantischen Analyse vorgenommen 

werden können. Hierzu gehört z.B. die korrekte Typisierung von Ausdrücken. 

Die dynamische Typüberprüfung findet erst zur Laufzeit eines übersetzten 

Programms statt, da sie die Typinformationen analysiert, die von der Eingabe des 

jeweiligen Programmablaufs abhängig sind. Hierzu gehört z.B. die Einhaltung der 

Indexmenge bei Arrayzugriffen. 

Eine Programmiersprache heißt streng getypt, wenn eine vollständige statische Typüberprüfung 

eines Quelltextes zur Übersetzungszeit möglich ist (ohne Überprüfung der 

korrekten Indizierung bei Arrays). Streng getypte Sprachen sind z.B. Pascal [JW91], 

Modula-2 [Wir97], C [KR90] und Haskell [Po96]. Nicht streng getypt ist z.B. Smalltalk, 

da durch das late binding Typinformationen erst zur Laufzeit entstehen [GR83] 

und daher auch erst zur Laufzeit überprüft werden kann, ob eine Methode (oder ein 

Operator) für ein Objekt definiert ist. 

Beispiel 51 (Typüberprüfer für eine einfache Sprache) 

Wir definieren eine einfache Sprache, in der ein Programm aus einer Folge von Deklarationen 

besteht, auf die ein einzelner Ausdruck folgt. Die kontextfreie Grammatik 

dieser Sprache lautet: 

3 In Modula-2 als open arrays generell erlaubt. 

131


P → D ; E 

D → D ; D | id : T 

T → char | integer | array [ num ] of T | ↑ T 

E → literal | num | id | E mod E | E [ E ] | E ↑ 

Als Typen verwenden wir einfache Typen (char, integer und type error für Typfehler) 

und Arrays und Zeiger als zusammengesetzte Typen. Alle Arrays sind mit Werten 

vom Typ integer indiziert; die Indexmengen beginnen stets mit 1. So liefert z.B. der 

Deklarationsteil array [256] of char den Typausdruck array(1..256,char). Zeigertypen 

werden mit dem Typkonstruktor pointer bezeichnet, so daß z.B. ↑integer den 

Typ pointer(integer) erhält. Die Dereferenzierung geschieht in Ausdrücken mit e ↑, 

wobei e einem Zeigertyp angehören muß. 

Wir geben nun das Typsystem für unsere Sprache in Form von semantischen Regeln 

an, die den Produktionen der Grammatik zugeordnet sind. 

Für die semantischen Regeln verwenden wir zwei Funktionen mit Seiteneffekten: 

• addtype(b,t) ordnet dem Bezeichner b in der Symboltabelle den Typ t zu. Wir 

nehmen an, daß die Bezeichner während der lexikalischen Analyse in die Symboltabelle 

eingefügt wurden. Jedes Symbol id besitzt ein synthetisches Attribut 

entry, das auf den entsprechenden Symboltabelleneintrag verweist. 

• lookup(b) liefert den für Bezeichner b in der Symboltabelle angegebenen Typ. 

Existiert in der Symboltabelle kein Eintrag für b, liefert lookup type error. 

Das Symbol num besitzt ein synthetisches Attribut val, das den Wert der von num 

repräsentierten Zahl enthält. 

Die semantischen Regeln des Typsystems sind in Abbildung 4.9 angegeben. 

In der Regel für Array-Zugriff wird nicht überprüft, ob der Index gültig ist, da dies 

erst von der dynamischen Typüberprüfung zur Laufzeit verifiziert werden kann. 

In Abbildung 4.10 ist der attributierte Strukturbaum für das Programm 

n : ↑ integer; 

n↑ mod 4 

angegeben. Dieses Programm enthält keinen Typfehler. 

Das Programm 

n : ↑ integer; 

n↑ mod x 

ist syntaktisch korrekt, enthält aber einen semantischen Fehler, da der Bezeichner x 

nicht deklariert ist. Das Typsystem ist in der Lage, diesen Fehler zu finden (siehe 

Abbildung 4.11). Beim Nachsehen in der Symboltabelle liefert die Funktion lookup 

den Typ type error, der im Baum weitergereicht wird. Auf diese Weise wird erkannt, 

daß der Ausdruck einen semantischen Fehler enthält. 

132


P → D ; E 

D → D ; D 

D → id : T addtype(id.entry,T.type) 

T → char T.type := char 

T → integer T.type := integer 

T → ↑T T1.type := pointer(T2.type) 

T → array [ num ] of T T1.type := array(1..num.val,T2.type) 

E → literal E.type := char 

E → num E.type := integer 

E → id E.type := lookup(id.entry) 

E → E mod E E1.type := 

if E2.type = integer and E3.type = integer 

then integer 

else type error 

E → E [ E ] E1.type := 

if E3.type = integer and E2.type = array(s,t) 

then t 


E → E ↑ E1.type := 

if E2.type =pointer(t) then t else type error 

Abbildung 4.9: Semantische Regeln für Beispielsprache. 

addtype(n,pointer(integer)) 

D 

type:integer 

id : T 

E 

type:pointer(integer) 

entry:n 

P 

T 

type:integer 

integer 

; E 

mod 

E type:pointer(integer) 

id 

entry:n 

type:integer 

E 

num 

val:4 

type:integer 

Abbildung 4.10: Attributierter Strukturbaum für ein Beispielprogramm. 

133


addtype(n,pointer(integer)) 

D 

type:integer 

id : T 

E 

type:pointer(integer) 

entry:n 

P 

T 

type:integer 

integer 

; E 

mod 

E type:pointer(integer) id 

entry:? 

id 

entry:n 

type:type_error 

E 

type:type_error 

Abbildung 4.11: Attributierter Strukturbaum für ein fehlerhaftes Beispielprogramm. 


Wir erweitern die Sprache aus dem vorherigen Beispiel um Anweisungen. Anweisungen 

haben keinen Typ, daher führen wir einen neuen einfachen Typ void ein, der den 

Typ einer korrekt getypten Anweisung darstellt. 

Wir modifizieren die Grammatik aus Beispiel 51: 

P → D ; S 

D → D ; D | id : T 

T → boolean | char | integer | array [ num ] of T | ↑ T 

E → literal | num | id | E mod E | E [ E ] | E ↑ 

S → id := E | if E then S | while E do S | S ; S 

Das Typsystem wird um die folgenden semantischen Regeln ergänzt. 

134

1 function sequiv (S ,T) : boolean ; 

2 begin 

3 if S und T vom selben Basistyp then 

4 return true 

5 else if } S = array( I , S1) and T = array( I ,T1) then 

6 return sequiv (S1 ,T1) 

7 else if S = pointer (S1) and T = pointer (T1) then 

8 return sequiv (S1 ,T1) 

9 else return false 

10 end 


Abbildung 4.12: Funktion zur Überprüfung, ob zwei Typausdrücke identisch sind. 

T → boolean T.type := boolean 

S → id := E S.type := 

if lookup(id.entry) = E.type 

then void 


S → if E then S S1.type := 

if E.type = boolean 

then S2.type 


S → while E do S S1.type := 

if E.type = boolean 

then S2.type 


S → S ; S S1.type := 

if S2.type = void and S3.type = void 

then void 


4.2.2 Gleichheit von Typausdrücken 

Im Beispiel 52 wurde in der semantischen Regel für die Wertzuweisung die Gleichheit 

von Typausdrücken gefordert (if lookup(id.entry) = E.type ...). 

Wir gehen im folgenden auf die Frage ein, wann zwei Typen gleich sind. 

In einem Typsystem ohne die Deklaration neuer Typnamen sind zwei Typen gleich, 

wenn ihre Typausdrücke identisch sind. Zur Überprüfung, ob zwei Typausdrücke 

identisch sind, läßt sich die rekursive Funktion sequiv in Abbildung 4.12 verwenden. 

135


Beispiel 53 

Ein Problem entsteht, wenn die Vergabe von Typnamen für neue Typen möglich ist. 

Betrachten wir die folgende Typdeklaration: 

type link = ↑ cell; 

var next : link; 

last : link; 

p : ↑ cell; 

q,r : ↑ cell; 

Haben next,last,p,q und r den gleichen Typ? 

Werden Typnamen verwendet, unterscheiden wir zwei Arten von Typgleichheit: Namensgleichheit 

und strukturelle Gleichheit. 

• Namensgleichheit: jeder Typname bezeichnet einen individuellen Typ. Daher 

sind die Typnamen Bestandteile der Typausdrücke. 

• Strukturelle Gleichheit: die Typnamen werden in Typausdrücken ersetzt, bevor 

die Funktion sequiv aus Abbildung 4.11 auf die Typausdrücke angewendet wird 

(Vorsicht bei rekursiven Typdefinitionen!). 


Den in Beispiel 53 deklarierten Variablen werden die folgenden Typausdrücke zugeordnet: 

next : link 

last : link 

p : pointer(cell) 

q : pointer(cell) 

r : pointer(cell) 

Bei Namensgleichheit besitzen next und last den gleichen Typ, ebenso p, q und r. p 

und next hingegen sind nicht vom gleichen Typ. 

Bei struktureller Gleichheit werden die Typnamen durch die ihnen zugeordneten Typausdrücke 

ersetzt. Da link der Ausdruck pointer(cell) zugeordnet ist, besitzen alle 

fünf Variablen den gleichen Typ. 

In der Praxis ist das Problem der Typgleichheit manchmal noch komplizierter. Zum 

Beispiel wird in Implementierungen der Sprache Pascal für jede Deklaration ein 

impliziter Typname eingeführt. Daher würden die Typen der Variablen aus Beispiel 

53 lauten: 

next : link 

last : link 

p : np 

q : nqr 

r : nqr 

136


Die Variable p erhält den neuen impliziten Typnamen np. Die Variablen q und r 

erhalten den neuen impliziten Typnamen nqr, da sie zusammen in einer Deklaration 

vereinbart wurden. Dies führt dazu, daß p und q nicht mehr vom gleichen Typ sind, 

q und r jedoch schon. 

4.2.3 Typumwandlungen 

In einigen Fällen ist die Gleichheit von Typen eine zu starke Forderung, wie im 

folgenden Beispiel erläutert wird. 

Beispiel 55 

Im Programm 

var x,y : real; 

i : integer; 

y := x + i 

wird eine Addition einer Variable x vom Typ real mit einer Variable i vom Typ 

integer durchgeführt, deren Ergebnis wieder in einer real-Variable gespeichert wird. 

In einigen Programmiersprachen (z.B. in Oberon [WG92]) ist diese Addition erlaubt, 

obwohl die Typen von x und i unterschiedlich sind. In diesen Sprachen sind die 

Typen real und integer “verträglich”, d.h. der Wert der integer-Variable wird vor 

der Durchführung der Addition in einen real-Wert umgewandelt. 

Wir definieren die “Verträglichkeit” von Typen durch eine Relation coercible (engl. 

coercible = erzwingend). 

Definition 51 

Seien T1,T2 Typen. Die Beziehung coercible(T1,T2) legt fest, daß ein Objekt vom Typ 

T1 in ein Objekt vom Typ T2 transformiert werden kann, falls dies nötig ist. 

Die Notwendigkeit einer Transformation eines Objekts in ein Objekt eines “verträglichen” 

Typs wird vom Compiler in der semantischen Analyse erkannt, so daß er für 

diese Umwandlung Code erzeugen kann. 

Beispiel 56 (Typüberprüfung für Ausdrücke) 

In diesem Beispiel betrachten wir ein Typsystem für Ausdrücke, das Typumwandlungen 

erlaubt. Jeder Ausdruck besitzt zwei Attribute für die Aufnahme von Typinfomationen: 

• Das synthetische Attribut premode enthält den Typ eines Ausdrucks gemäß 

seiner Zusammensetzung. 

• Das inherite Attribut postmode enthält den Typ eines Ausdrucks, der gemäß 

des Kontexts erwartet wird. 

137


Die folgende kontextfreie Grammatik definiert Wertzuweisungen, deren Ausdrücke 

nur den Additionsoperator enthalten dürfen. 

S → name := E 

E → name addop name 

addop → + 

name → id 

Als Typen lassen wir real und integer zu. Dabei soll gelten, daß ein integer-Wert in 

einen real-Wert umgewandelt werden kann, falls als Ergebnis des Gesamtausdrucks 

ein real-Wert erwartet wird. 

Es soll also gelten: 

coercible(integer,integer) = true 

coercible(integer,real) = true 

coercible(real,real) = true 

coercible(real,integer) = false 

Zur Beschreibung des Typsystems verwenden wir die folgenden semantischen Regeln: 

S → name := E name.postmode := name.premode 

E.postmode := 

if name.premode = integer 

then integer 

else real 

E → name addop name name1.postmode := E.premode 

name2.postmode := E.premode 

addop.postmode := E.premode 

E.premode := 

if coercible(name1.premode,integer) 

and coercible (name2.premode,integer) 

then integer 

else real 

addop → + +.operation := 

if addop.postmode = integer 

then int addition 

else real addition 

name → id name.premode := lookup(id.entry) 

Anmerkungen zu den semantischen Regeln: 

138 

• Die Regel zur Berechnung von E.premode überprüft, ob der Wert des jeweiligen 

premode-Attributs der Nichtterminale name mit dem Typ integer verträglich 

ist. Ist dies der Fall, wird als Ergebnistyp des Ausdrucks integer verwendet, 

andernfalls real. 

• Zur Produktion E → name addop name kann eine semantische Bedingung angegeben 

werden, die durch einen Vergleich von E.premode und E.postmode

S 

name postmode:real := 

E 

premode:real 

id 

entry:X 

postmode:integer 

premode:integer 

name addop 

name 


entry:I 

postmode:real 


id + 

id 

operation:int_addition 




entry:J 

Abbildung 4.13: Attributierter Strukturbaum einer Zuweisung. 

S 

name postmode:real := 

E 

premode:real 

id 

entry:X 



name addop 

name 


entry:I 

postmode:real 


id + 

id 

operation:int_addition 

Typumwandlung 



entry:J 

Abbildung 4.14: Attributierter Strukturbaum einer Zuweisung mit Attributabhängigkeiten. 

eine Überprüfung auf Vorliegen eines Typfehlers vornimmt. Es muß gelten 

coercible(E.premode,E.postmode), d.h. ein Fehler liegt vor, sobald der Ausdruck 

aufgrund seiner Struktur einen real-Wert liefert und aufgrund des Kontextes 

ein integer-Wert erwartet wird (coercible(real,integer) = false). 

• Das inherite Attribut +.operation wird als Information für die Codegenerierung 

benötigt. Durch die Überladung des Additionsoperators +, der sowohl die 

integer- als auch die real-Addition repräsentiert, kann der Codegenerator anhand 

des Werts dieses Attributs erkennen, für welche Art der Addition er Code 

erzeugen muß. 

In Abbildung 4.13 ist der attributierte Strukturbaum der Analyse der Zuweisung 

X:=I+J angegeben. Wir nehmen an, daß X eine Variable vom Typ real ist und I 

und J Variablen von Typ integer sind. In Abbildung 4.14 wurde der Strukturbaum um 

die Attributabhängigkeiten ergänzt. Für das Nichtterminal E unterscheiden sich die 

Attributwerte von postmode und premode. Da jedoch coercible(integer,real) = true 

gilt, kann eine Typumwandlung vorgenommen werden, so daß die Zuweisung korrekt 

getypt ist. 

139


S 

name 


:= 

E 


id 

entry:X 

postmode:real 

premode:real 

entry:I 

name addop 

postmode:real 

id + 


premode:real 

operation: 

real_addition 

Typfehler 

name 

id 

postmode:real 


entry:J 

Typumwandlung 

Abbildung 4.15: Attributierter Strukturbaum einer Zuweisung mit Typfehler. 

Wir ändern die den Variablen zugeordneten Typen: sei nun X vom Typ integer 

und I vom Typ real. Der attributierte Strukturbaum der Zuweisung ist Abbildung 

4.15 dargestellt. Die semantische Analyse entdeckt einen Typfehler, da das Attribut 

premode von E den Wert real, das Attribut postmode den Wert integer besitzt 

und coercible(real,integer) = false gilt. Vor der Feststellung des Fehlers wird für 

die Variable J eine Typumwandlung durchgeführt, um den integer-Wert von J zum 

real-Wert von I addieren zu können. Aufgrund der Zusammensetzung des Ausdrucks 

erhält E.premode den Wert real. Aus dem Kontext der Zuweisung (X ist integer- 

Variable) erhält E.postmode den Wert integer, so daß ein Typfehler vorliegt, der bei 

der Verträglichkeitsprüfung dieser beiden Attribute bemerkt wird. 

140

5 Zwischencode-Erzeugung 

Nachdem in den Kapiteln 2, 3 und 4 die einzelnen Phasen der Analyse eines Quelltexts 

behandelt wurden, werden in den folgenden Kapiteln die Synthesephasen beschrieben. 

Die erste Synthesephase ist die Zwischencode-Erzeugung. Zwischencode ist Code für 

eine abstrakte (oder virtuelle) Maschine. Abstrakte Maschinen werden im Gegensatz 

zu realen Maschinen durch Programme realisiert, die den vom Compiler erzeugten 

Zwischencode interpretieren. Da Zwischencode von abstrakten Maschinen ausgeführt 

wird und somit von einer konkreten Zielmaschine unabhängig ist, wird die 

Zwischencode-Erzeugung zum Front-End eines Compilers gezählt (Abbildung 5.1, 

siehe auch Seite 12). 

Die Erzeugung von Code für eine abstrakte Maschine statt für eine reale Maschine 

bietet mehrere Vorteile: 

• Übersetzte Programme können auf allen Rechnern und unter allen Betriebssystemen 

laufen, für die ein Programm existiert, das die abstrakte Maschine 

realisiert. Beispiele für die erhöhte Portabilität durch Verwendung einer abstrakten 

Maschine sind das UCSD-System [Güt85] mit der p-Maschine und das 

Java-System [LY99]. 

• Neben der Portabilität übersetzter Programme wird die Portierung von Übersetzern 

wesentlich vereinfacht, da der Zwischencode-Generator nicht jedesmal 

neu implementiert werden muß, um an die veränderte Hard- und Software angepaßt 

zu werden. 

• Durch die Verwendung von Zwischencode ist eine maschinenunabhängige Co- 

Parser 

semantische Zwischen- 

Analyse 

codegenerator 

Zwischendarstellung 

Front-End Back-End 

Zwischencode 

Abbildung 5.1: Einordnung der Zwischencode-Erzeugung. 

Codegenerator 

141


deoptimierung möglich. Diese kann z.B. Codeabschnitte, die nie durchlaufen 

werden können, aus dem Code entfernen. 

• Die Architektur heutiger Hardwaremaschinen orientiert sich an der Struktur 

des von-Neumann-Rechners. Diese beruht auf der Verwendung von Speicher 

in Form von Variablen und einer Steuerung des Programmflusses durch bedingte 

und unbedingte Sprünge. Im Gegensatz zu den imperativen Sprachen 

wie C [KR90] oder Modula-2 [Wir97] lassen sich funktionale Sprachen wie ML 

[HMM97, Pau96] und Haskell [Po96] sowie logische Sprachen wie Prolog [CM94] 

nur unter großem Aufwand auf diese Maschinen abbilden. Aus diesem Grund 

kann eine abstrakte Maschine, die in ihrer Struktur auf die Bearbeitung der 

Konstrukte solcher Sprachen hin optimiert ist, die Codeerzeugung wesentlich 

vereinfachen. Beispiele für solche Maschinen sind die MaMa für funktionale 

Sprachen und die Warren Abstract Machine für Prolog [WM96]. 

Der wesentliche Nachteil abstrakter Maschinen ist der Verlust an Effizienz, der durch 

die Interpretation des Zwischencodes durch die abstrakte Maschine entsteht. Außerdem 

können bei größeren Programmen Speicherplatzprobleme entstehen, da der 

Speicher neben dem auszuführenden Programm auch die abstrakte Maschine enthalten 

muß. Allerdings ist durch die spezielle Struktur der abstrakten Maschine der 

Zwischencode meist kürzer als der Code für die reale Maschine, da ein Befehl des 

Quelltexts meist in eine kurze Folge von Befehlen der abstrakten Maschine übersetzt 

werden kann. 

Es gibt verschiedene Arten der Darstellung von Zwischencode. In den folgenden Abschnitten 

werden wir auf zwei verbreitete Arten eingehen. 

5.1 Abstrakte Keller-Maschinen 

Reale Hardware-Maschinen besitzen in der Regel eine große Anzahl von internen 

Registern, in denen die arithmetischen und logischen Operationen ausgeführt werden. 

Die dazu benötigten Werte werden zuvor, sofern sie sich noch nicht in Registern 

befinden, aus dem Hauptspeicher geladen. Das Ergebnis der Operation wird ebenfalls 

in Registern abgelegt und kann bei Bedarf in den Hauptspeicher geschrieben werden 

(siehe auch Kapitel ??). 

Im Gegensatz hierzu besitzen abstrakte Keller-Maschinen keine für den Benutzer 

verwendbaren Register. Statt dessen werden die Daten auf einem Keller abgelegt. 

Die arithmetischen und logischen Operationen finden stets auf den obersten Werten 

des Kellers statt, die bei der Durchführung einer Operation vom Keller entfernt 

und durch das Ergebnis ersetzt werden. Zur Erzeugung von Zwischencode für eine 

abstrakte Keller-Maschine benötigen wir das Konzept der Postfix-Notation, in der 

der Operator hinter seine Operanden geschrieben wird. 

142

Beispiel 57 (Übersetzung arithmetischer Ausdrücke) 


Die Postfix-Notation eines Ausdrucks kann gemäß den folgenden Regeln berechnet 

werden: 

E = id ⇒ postfix(E) = E 

E = E1 op E2 ⇒ postfix(E) = postfix(E1) postfix(E2) op 

E = ( E1 ) ⇒ postfix(E) = postfix(E1) 

In Postfix-Ausdrücken sind Klammern überflüssig, da Position und Stelligkeit der 

Operanden nur eine Interpretation eines Ausdrucks zulassen. 

Wir geben ein Beispiel für eine Überführung des Infix-Ausdrucks (3 + 4) ∗ (5 − 2) in 

Postfix-Notation an: 

postfix((3 + 4) ∗ (5 − 2)) 

= postfix((3 + 4)) postfix((5 − 2)) ∗ 

= postfix(3 + 4) postfix(5 − 2) ∗ 

= postfix(3) postfix(4) + postfix(5) postfix(2) − ∗ 

= 3 4 + 5 2 − ∗ 

Zur vereinfachten Übertragung eines Ausdrucks in Postfix-Notation führen wir Syntaxbäume 

ein. 

5.1.1 Syntaxbäume 

Syntaxbäume stellen wie die in Kapitel 3 eingeführten Strukturbäume die Struktur 

eines Quellprogramms dar. Syntaxbäume enthalten im Gegensatz zu Strukturbäumen 

aber keine Nichtterminale. Die Blätter von Syntaxbäumen sind mit Bezeichnern 

und Werten beschriftet, die inneren Knoten mit Operatorsymbolen. Auf diese Weise 

repräsentieren Syntaxbäume die hierarchische Struktur des Quellprogramms. 

Beispiel 58 (Arithmetische Ausdrücke mit negativen Operanden) 

Die folgende Grammatik beschreibt die Syntax von Zuweisungsoperatoren. 

S → id:=E 

E → E + E | E * E | -E | ( E ) | id 

Die Ausdrücke zur Berechnung des zuzuweisenden Wertes können ein negatives Vorzeichen 

besitzen. Wir nehmen an, daß die üblichen Prioritäten der arithmetischen 

Operatoren gelten. 

In Abbildung 5.2 ist der Syntaxbaum für die Anweisung a := b∗(−c)+b∗(−c) dargestellt. 

Die Wurzel des Baums repräsentiert den Zuweisungsoperator, der linke Teilbaum 

den Bezeichner, dem der berechnete Wert zugewiesen werden soll, und der 

rechte Teilbaum den auszuwertenden Ausdruck. 

143


assign 

a + 

* 

b minus 

* 

b minus 

c c 

Abbildung 5.2: Syntaxbaum 

Die Postfix-Notation ist eine linearisierte Darstellung eines Syntaxbaumes. Durchläuft 

man den Baum nach dem Postorder-Verfahren (für jeden Knoten werden zuerst der 

linke und der rechte Teilbaum durchlaufen), ergibt sich die Darstellung des Ausdrucks 

in Postfix-Notation. 


Ein Postorder-Durchlauf durch den Syntaxbaum in Abbildung 5.2 erzeugt daher die 

folgende Darstellung in Postfix-Notation: 

a b c minus ∗ b c minus ∗ + assign 

Ein Strukturbaum kann mit Hilfe attributierter Grammatiken in einen Syntaxbaum 

überführt werden. Hierzu werden als Attribute Zeiger verwendet, die die einzelnen 

Knoten des neu erzeugten Syntaxbaums miteinander verbinden. 


Folgende attributierte Grammatik erzeugt den Syntaxbaum für den oben angegebenen 

Ausdruck: 

S → id:= E S.nptr := mknode(’assign’,mkleaf(id, id.place), E.nptr) 

E → E + E E1.nptr := mknode(’+’, E2.nptr, E3.nptr) 

E → E * E E1.nptr := mknode(’*’, E2.nptr, E3.nptr) 

E → -E E1.nptr := mknode(’minus’, E2.nptr) 

E → ( E ) E1.nptr := E2.nptr 

E → id E.nptr := mkleaf(id, id.place) 

Der generierte Syntaxbaum ist in Abbildung 5.3 dargestellt. Für jeden Bezeichner 

des Ausdrucks wird ein Blatt erzeugt (mit der Funktion mkleaf). Für die Operatoren 

werden mit der Funktion mknode innere Knoten generiert. Diese besitzen als Komponenten 

Zeiger, die auf den linken bzw. den rechten Teilbaum des jeweiligen Knotens 

verweisen. 

144

assign 

id a 

+ 

* * 

id b id b 

minus minus 

id c id c 


0 

1 

2 

3 

4 

5 

6 

7 

8 

9 

10 

11 

id 

id 

minus 

b 

c 

1 

* 0 2 

id b 

id c 

minus 5 

* 4 6 

+ 3 7 

id a 

assign 9 8 

Abbildung 5.3: Konstruktion eines Syntaxbaums aus Postfix-Notation. 

. . . 

145


5 

9 

45 

Abbildung 5.4: Auswertung eines Postfix-Ausdrucks mit Hilfe eines Stacks. 

Syntaxbäume lassen sich auch in Form von Tabellen angeben. In der rechten Hälfte 

von Abbildung 5.3 ist eine solche Tabelle für den eben erzeugten Syntaxbaum angegeben. 

Die Zeiger werden nun durch die Zeilennummern repräsentiert. 

Die Postfix-Darstellung der Anweisung ist dem Zwischencode für eine Stackmaschine 

bereits sehr ähnlich, da diese Darstellung schon zur Auswertung mit Hilfe eines Stacks 

geeignet ist. 

Dabei wenden wir das folgende Verfahren an: 

• Wir durchlaufen den Postfix-Ausdruck von links nach rechts. 

• Ist das aktuelle Symbol ein Wert, wird dieser Wert auf den Stack gelegt und 

bildet somit die neue Kellerspitze. 

• Handelt es sich bei dem aktuellen Symbol um einen Operator, werden so viele 

Werte vom Stack entfernt, wie der Operator zur Auswertung Operanden 

benötigt (die Anzahl der zu entfernenden Werte entspricht der Stelligkeit des 

Operators). Aus diesen Werten wird das Ergebnis berechnet und auf den Stack 

gelegt. 

Beispiel 61 

Wir berechnen den Ausdruck 9 * 5 + 2. Zuerst wird der Ausdruck in Postfix-Notation 

transformiert: 

postfix( 9 * 5 + 2 ) = postfix(( 9 * 5 ) + 2 ) 

= 9 5 * 2 + 

Nun wird der generierte Postfix-Ausdruck mit Hilfe eines Stacks ausgewertet (siehe 

Abbildung 5.4). Zuerst wird der Wert 9 auf den Stack gelegt. Danach folgt der Wert 

5, der ebenfalls auf den Stack gelegt wird. Beim nächsten Symbol handelt es sich um 

den Operator *. Dieser besitzt die Stelligkeit 2, so daß zwei Werte vom Stack entfernt 

werden müssen. Aus diesen Werten wird das Ergebnis 45 berechnet und auf den Stack 

gelegt. Danach wird die 2 auf den Stack gelegt und durch den Additionsoperator mit 

dem Ergebnis der Multiplikation verknüpft. 

146 

2 

45 

47

5.1.2 Zwischencode für die Keller-Maschine 


Nachdem wir im vorherigen Abschnitt das Konzept der Auswertung von Postfix- 

Ausdrücken erläutert haben, definieren wir nun den Befehlssatz der abstrakten Keller- 

Maschine. Weiterhin beschreiben wir die Erzeugung von Zwischencode durch attributierte 

Grammatiken. 

Wir nehmen an, daß der Befehlssatz der abstrakten Keller-Maschine die folgenden 

Befehle beinhaltet: 

ADD Addition der obersten beiden Stack-Elemente. 

Diese werden entfernt, und das Ergebnis wird auf den Stack gelegt. 

SUB Subtraktion. 

MUL Multiplikation. 

LOAD v Lege Wert v auf den Stack. 

; Sequentielle Komposition. 

Zur Erzeugung des Zwischencodes für Ausdrücke mit einer attributierten Grammatik 

führen wir ein synthetisches Attribut Code ein und definieren die Grammatik wie 

folgt: 

E → E + T E1.Code := E2.Code; T.Code; ADD 

E → E - T E1.Code := E2.Code; T.Code; SUB 

E → T E.Code := T.Code 

T → T * F T1.Code := T2.Code; F.Code; MUL 

T → F T.Code := F.Code 

F → ( E ) F.Code := E.Code 

F → 0 F.Code := LOAD 0 

. 

F → 9 F.Code := LOAD 9 

Bei der Übersetzung der Operatoren wird zunächst Code für die Auswertung der 

Operanden erzeugt. Nach Ausführung dieser Codeabschnitte befinden sich ihre Werte 

auf dem Stack und können dann durch den entsprechenden arithmetischen Befehl 

verknüpft werden. 


Das anhand der attributierten Grammatik erzeugte Programm für die Stack-Maschine 

lautet dann: 

LOAD 9; LOAD 5; MUL; LOAD 2; ADD 

Der attributierte Strukturbaum ist in Abbildung 5.5 angegeben. 

5.1.3 Befehle zur Steuerung des Kontrollflusses 

Bisher enthielt der Befehlssatz nur die sequentielle Komposition zur Steuerung des 

Kontrollflusses. Nun führen wir als neue Zwischencodebefehle bedingte und unbeding- 

147


148 

LOAD 9 

LOAD 9 

LOAD 9;LOAD 5;MUL 

T 

T * 

F 

9 

E 

E + T 

LOAD 9;LOAD 5;MUL 

F 

5 

LOAD 5 

LOAD 9;LOAD 5;MUL;LOAD 2;ADD 

F 

2 

LOAD 2 

LOAD 2 

Abbildung 5.5: Attributierter Strukturbaum mit Zwischencode.


te Sprünge ein. Hierbei verwenden wir anstelle von Speicheradressen Sprungmarken 

zur Angabe des Ziels von Sprungbefehlen. 

Wir erweitern den in Abschnitt 5.1.2 eingeführten Befehlssatz um die folgenden Befehle: 

LABEL l Definition der Sprungmarke l. 

GOTO l Sprung zu der Anweisung nach Sprungmarke l 

GOFALSE l Entfernen des obersten Stack-Elements, 

Sprung falls 0. 

GOTRUE l Sprung falls �= 0. 

HALT Beenden der Programmausführung. 

Der Befehl LABEL definiert eine Sprungmarke, die von den Sprungbefehlen als 

Sprungziel verwendet werden kann. Wird ein Sprung ausgeführt, wird die Programmausführung 

mit dem der Marke folgenden Befehl fortgesetzt. GOTO ist ein unbedingter 

Sprung. Die Befehle GOFALSE und GOTRUE sind bedingte Sprünge, die einen 

Sprung in Abhängigkeit des Werts an der Kellerspitze ausführen. Hierbei wird eine 

semi-boolesche Logik 1 verwendet, in der 0 den Wert false repräsentiert und alle anderen 

Werte als true interpretiert werden. Befindet sich an der Kellerspitze der Wert 

0, führt GOFALSE den Sprung durch, andernfalls wird mit dem nächsten Befehl 

fortgefahren. Entsprechend springt GOTRUE, wenn die Kellerspitze einen anderen 

Wert als 0 enthält. In jedem Fall wird der oberste Kellerwert entfernt. 

Im folgenden betrachten wir die Darstellung der aus imperativen Sprachen bekannten 

Kontrollstrukturen if und while im Zwischencode. Weitere Konstrukte wie z.B. die 

repeat-Schleife lassen sich analog darstellen. Wir nehmen an, daß für die relationalen 

Operationen wie , = Zwischencodebefehle existieren, die die Werte 0 (für false) 

bzw. 1 (für true) auf den Stack legen. 

1 Wie in der Sprache C. 

149


if-Anweisung und while-Schleife: 

Die folgende Grammatik definiert eine if-Anweisung ohne else-Alternative und die 

while-Schleife: 

stmt → if expr then stmt end | 

while expr do stmt end | 

stmt; stmt 

Die if-Anweisung läßt sich im Zwischencode durch folgendes Schema darstellen: 

Code für expr; (legt semi-boolschen Wert auf den Stack) 

GOFALSE out; 

Code für stmt; 

LABEL out 

Zunächst wird Code für die Berechnung des booleschen Ausdrucks generiert. Dieser 

legt als Ergebnis entweder 0 (für false) oder 1 (für true) auf den Keller. Ist der 

Wert 0, sollen Befehle nach dem then nicht ausgeführt werden. Dies wird durch den 

Sprungbefehl GOFALSE realisiert, der in diesem Fall an das Ende des Codes für die 

if-Anweisung verzweigt. 

Analog wird die while-Schleife durch das folgende Schema realisiert: 

LABEL test; 

Code für expr; 

GOFALSE out; 

Code für stmt; 

GOTO test; 

LABEL out 

Zunächst wird wieder Code für die Auswertung des Ausdrucks erzeugt. Legt dieser 

Code nach Ausführung den Wert 0 auf den Stack, wird der Schleifenrumpf nicht 

mehr ausgeführt, indem mit GOFALSE ans Ende der Schleife verzweigt wird. Wird 

der Schleifenrumpf ausgeführt, wird anschließend mit GOTO wieder an den Anfang 

der Schleife gesprungen und der Code für die Berechnung von expr erneut ausgeführt. 

Enthält ein Programm mehrere if- oder while-Anweisungen, müssen bei der Übersetzung 

jeder dieser Anweisungen neue Sprungmarken erzeugt werden. Daher nehmen 

wir im folgenden an, daß eine Funktion newlabel zur Verfügung steht, die in jedem 

Aufruf eine neue Sprungmarke generiert. 

Hinzu kommt, daß die Kontrollflußanweisungen auch verschachtelt auftreten dürfen. 

Daher muß eine Verwaltung der Sprungmarken gewährleisten, daß die Sprungbefehle 

und die zugehörigen Marken die Verschachtelung der Anweisungen korrekt widerspiegeln. 

Dies erreichen wir, indem wir spezielle Attribute für das Zwischenspeichern 

von Marken verwenden. 

Wir betrachten als Beispiel die Produktion für die if-Anweisung: 

150

5.2 Drei-Adreß-Code 

stmt → if expr then stmt end 

stmt1.out := newlabel 

stmt1.Code := expr.Code; 

GOFALSE stmt1.out; 

stmt2.Code; 

LABEL stmt1.out 

Wir verwenden ein Attribut out, das die von der Funktion newlabel erzeugte Sprungmarke 

speichert. Die GOFALSE- und LABEL-Befehle verwenden dann die in diesem 

Attribut gespeicherte Sprungmarke. Entsprechendes gilt für den Code der while- 

Schleife. 

Beispiel 63 (Geschachtelte if-Anweisung) 

Wir übersetzen eine geschachtelte if-Anweisung in Zwischencode für die abstrakte Kellermaschine. 

Hierbei nehmen wir an, daß die Funktion newlabel Zahlen als Sprungmarken 

generiert. 

Wir betrachten die folgende Anweisung: 

if e1 then if e2 then s end end ; other 

e1 und e2 repräsentieren Ausdrücke, s steht für eine Sequenz von Anweisungen. Der 

attributierte Strukturbaum für die Anweisung ist in Abbildung 5.6 dargestellt. Der 

Inhalt des Attributs Code wird durch Kästen angegeben, der Inhalt von out durch 

Kreise. 


Eine weitere Variante von Zwischencode ist der Drei-Adreß-Code. Im Vergleich zum 

Zwischencode für abstrakte Keller-Maschinen ist er näher an der “Maschinensprache” 

realer Maschinen einzuordnen. 

Wie der Zwischencode für die Keller-Maschine besteht der Drei-Adreß-Code aus einer 

Folge von Befehlen. Jeder Befehl gehört zu einem der folgenden Formate: 

x := y op z op ist ein arithmetischer oder logischer binärer 

Operator 

x := op y op ist unärer Operator 

z.B. log. Negation, Schiebe-Operation 

x := y Kopieranweisung 

goto l unbedingter Sprung 

if x relop y goto l bedingter Sprung: relop ist ein Vergleichsoperator 

Weiterhin gibt es spezielle Befehle zur Daten-/Speicher-Behandlung und für Prozedur- 

Aufrufe. 

151


Code(e1) 

GOFALSE1 

Code(e2) 

GOFALSE2 

Code(s) 

LABEL2 

LABEL1 

152 

Code 

out 

if then 

expr 

stmt 

Code(e1) 

if 

expr 

1 

2 

stmt 

; stmt 

end other 

stmt 

then end 

Code(e2) 

Code(e2) 

GOFALSE2 

Code(s) 

LABEL2 

stmt 

Code(e1) 

GOFALSE1 

Code(e2) 

GOFALSE2 

Code(s) 

LABEL2 

LABEL1 

Code(other) 

Code(s) 

Code(other) 

Abbildung 5.6: Attributierter Strukturbaum einer verschachtelten if-Anweisung.


Die Bezeichnung “Drei-Adreß-Code” kommt daher, daß alle Befehle der oben angeführten 

Formate maximal drei Adressen enthalten (zwei Adressen für die Operanden 

des Befehls und eine Adresse für die Speicherung des Ergebnisses). Im Gegensatz 

zur abstrakten Keller-Maschine, bei der die Werte und Zwischenergebnisse auf dem 

Keller verwaltet wurden, werden beim Drei-Adreß-Code die Werte und Ergebnisse in 

einem Arbeitsspeicher gehalten. Jeder Drei-Adreß-Befehl liest seine Operanden aus 

dem Speicher und schreibt das errechnete Ergebnis ebenfalls in eine Speicherzelle. 

Da jeder Drei-Adreß-Befehl maximal zwei Operanden verknüpfen kann, müssen komplexe 

Ausdrücke in Folgen von Befehlen übersetzt werden. Die dabei entstehenden 

Zwischenergebnisse werden in Speicherzellen abgelegt, die durch temporäre Namen 

gekennzeichnet sind. “Temporär” bedeutet in diesem Zusammenhang, daß die Namen 

nicht Bezeichnern des Quellprogramms entsprechen. 

Beispiel 64 

Im folgenden wird eine Übersetzung des Ausdrucks x+y∗z angegeben: 

x + y * z → t1 := y * z 

t2 := x + t1 

Aufgrund der Operatorprioritäten wird die Multiplikation zuerst ausgeführt und ihr 

Ergebnis in einem Speicherplatz mit temporärem Namen t1 zwischengespeichert. Der 

zweite Befehl addiert den Wert der Speicherzelle x zum Zwischenergebnis und legt 

das Ergebnis im temporären Speicherplatz t2 ab. 

5.2.1 Übersetzung von Syntaxbäumen in Drei-Adreß-Code 

Bei der Übersetzung eines Syntaxbaums in Drei-Adreß-Code müssen zuerst die temporären 

Namen für die Ablage von Zwischenergebnissen vereinbart werden. Dies geschieht, 

indem die inneren Knoten des Syntaxbaums mit temporären Namen beschriftet 

werden. 

Beispiel 65 

Wir übersetzen die Anweisung a := b∗(−c)+b∗(−c) aus Beispiel 58 in Drei-Adreß- 

Code. Hierzu beschriften wir die inneren Knoten des Syntaxbaums aus Abbildung 

5.2, die Zwischenergebnisse repräsentieren, mit den temporären Namen t1 bis t5. 

(Abbildung 5.7). 

Nachdem die temporären Namen vergeben sind, kann aus dem Syntaxbaum Drei- 

Adreß-Code erzeugt werden. Hierzu wird der Baum im Postorder-Verfahren durchlaufen, 

so daß vor der Bearbeitung eines Knotens zuerst seine Teilbäume ausgewertet 

werden. Für jeden mit einem temporären Namen beschrifteten Knoten wird ein 

Drei-Adreß-Befehl generiert. Als Zieladresse des Befehls wird der temporäre Name 

153


assign 

a + 

* 

t2 

b minus 

t1 

t5 

* 

t4 

b minus 

c c 

Abbildung 5.7: Syntaxbaum mit temporären Namen. 

verwendet. Die Operanden ergeben sich aus den Beschriftungen der Kinder des Knotens. 

Ebenso wird mit jedem Knoten verfahren, der einen Speicherplatz repräsentiert, 

auf den schreibend zugegriffen wird. 


Ein Postorder-Durchlauf durch den in Abbildung 5.7 angegebenen Syntaxbaum nach 

dem eben erläuterten Verfahren generiert die folgende Sequenz von Drei-Adreß-Befehlen: 

t1 := -c 

t2 := b * t1 

t3 := -c 

t4 := b * t3 

t5 := t2 + t4 

a := t5 

Bemerkung: Der in dem Beispiel erzeugte Drei-Adreß-Code ist nicht optimal, da 

nicht beachtet wird, daß der Teilausdruck b∗(−c) zweimal auftritt. Aus diesem Grund 

ist die Verwendung der Speicherplätze t3 und t4 überflüssig und der vorletzte Befehl 

könnte zu t5 := t2 + t2 modifiziert werden. Auf diese Weise können zwei Befehle und 

zwei temporäre Speicherplätze eingespart werden. Im Rahmen der Codegenerierung 

in Kapitel ?? geben wir ein Verfahren an, daß die beschriebene Optimierung für 

mehrfach auftretende Teilausdrücke durchführt. 

154 

t3


5.2.2 Übersetzung in Drei-Adreß-Code unter Verwendung von 

attributierten Grammatiken 

Wir beschreiben nun die Generierung von Drei-Adreßcode mit Hilfe von attributierten 

Grammatiken. Wir verwenden dabei die auf Seite 147 angegebene kontextfreie 

Grammatik zur Beschreibung von Ausdrücken. Das Attribut Code speichert den zu 

einem Nichtterminal generierten Drei-Adreß-Code. Das Attribut place enthält den 

Namen des Speicherplatzes, in dem das Ergebnis eines Befehls abgelegt werden soll. 

Wir nehmen an, daß eine Funktion newtemp existiert, die bei jedem Aufruf einen 

neuen temporären Namen generiert. 

S → id := E S.Code := E.Code; 

id.place := E.place 

E → E + E E1.place := newtemp 

E1.Code := E2.Code; E3.Code; 

E1.place := E2.place + E3.place 

E → E * E (analog) 

E → -E E1.place := newtemp 

E1.Code := E2.Code; 

E1.place := - E2.place 

E → (E) E1.place := E2.place 

E1.Code := E2.Code 

E → id E1.place := id.place 

E1.Code := ... 

Bei der Übersetzung eines arithmetischen Operatores wird zunächst ein neuer temporärer 

Name erzeugt. Der Code für diesen Operator besteht aus dem Code für die 

Berechnung der Operanden. Anschließend wird ein Befehl angefügt, der die Inhalte 

der Speicherzellen, die die Zwischenergebnisse beinhalten, mit dem Operator verknüpft. 

Das Ergebnis wird in den zuvor generierten Zwischenspeicher geschrieben. 

Beispiel 67 

In Abbildung 5.8 ist der attributierte Syntaxbaum für die Anweisung a := b * ( 

- c ) + d angegeben. Die Codefolge aus Drei-Adreß-Befehlen wird schrittweise in 

einem Bottom-Up-Durchlauf zusammengesetzt, bis das Code-Attribut an der Wurzel 

die vollständige Befehlsfolge beinhaltet. Somit ergibt sich eine durch die Übersetzung 

folgende Sequenz von Drei-Adreß-Befehlen: 

t1 := - c 

t2 := b * t1 

t3 := t2 + d 

a := t3 

Die Übersetzung von Kontrollstrukturen erfolgt analog. Im Gegensatz zu den in 

Abschnitt 5.1.3 beschriebenen Befehlen GOFALSE und GOTRUE für die abstrak- 

155


place = a 

S 

id := 

E + E 

E * E 

id 

place = b 

place = b 

place = t2 

Code = t1 := -c; 

( 

- 

Code = t1 := -c; t2 := b * t1; 

t2 := b * t1 

E 

t3 := t2 + d; a := t3 

place = t1 

E 

id 

E 

Code = t1 := - c 

place = t1 

Code = t1 := - c 

place = t3 

Code = t1 := -c; t2 := b * t1; 

place = c 

place = c 

t3 := t2 + d 

id 

) 

place = d 

place = d 

Abbildung 5.8: Syntaxbaum mit Attributen für die Erzeugung von Drei-Adreß-Code. 

156

5.3 Vergleich der beiden Arten von Zwischencode 

te Keller-Maschine steht im Drei-Adreß-Code ein Befehl if x relop y goto l zur 

Verfügung, der Vergleichsoperation und Sprung in einem Befehl vereinigt. 

5.3 Vergleich der beiden Arten von Zwischencode 

In diesem Kapitel haben wir zwei unterschiedliche Arten von Zwischencode vorgestellt. 

Die Entscheidung für die Realisierung einer der beiden Methoden in einem 

Compiler hängt im wesentlichen vom angestrebten Ziel des Compilers ab. 

Die Darstellung von Zwischencode in Form von Code für abstrakte Keller-Maschinen 

ist geeignet, wenn eine weitere Übersetzung des Zwischencodes in die Maschinensprache 

einer realen Maschine nicht vorgesehen ist. Dies ist oft der Fall bei der Implementierung 

nicht-imperativer Programmiersprachen. Daher soll von der realen Hardware 

(Speicheradressen usw.) möglichst weit abstrahiert werden, um das Speichermanagement 

zu vereinfachen. Dies wird durch die Verwaltung der Daten und Variablen auf 

einem Stack erreicht. 

Der Drei-Adreß-Code hingegen ist gut geeignet für die Anwendung von Optimierungsverfahren. 

Daher bietet sich seine Verwendung an, wenn die Erstellung von 

Zwischencode nur als Vorstufe für die eigentliche Codegenerierung vorgesehen ist. 

Durch die Anwendung von Optimierungsverfahren kann eine maschinenunabhängige 

Codeoptimierung vorgenommen werden. Zudem ist der Drei-Adreß-Code “maschinennäher” 

als der Code für die Keller-Maschine, da er nicht im selben Maße von den 

Gegebenheiten der Hardware abstrahiert. 

157

Literaturverzeichnis 

[Aho08] Sethi und Ullman Aho. Compiler. Prinzipien, Techniken und Werkzeuge. 

Pearson Studium, 2008. i 

[AK97] Heiko Vogler Armin Kühnemann. Attributgrammatiken. Eine grundlegende 

Einführung. Vieweg+Teubner, 1997. 

[ANT] ANTLR Parser Generator (http://www.antlr.org/). 117 

[ASU99] Alfred V. Aho, Ravi Sethi, Jeffrey D. Ullman. Compilerbau, Teil 1+2. 

Oldenbourg, 1999. 5, 8, 111, 113, 116, 128 

[AU72] Alfred V. Aho, Jeffrey D. Ullman. The Theory of Parsing, Translation, 

and Compiling. Addison-Wesley, 1972. 43 

[Bar83] J.G.P. Barnes. Programmieren in ADA. Hanser, 1983. 118 

[CM94] William F. Clocksin, Christopher S. Mellish. Programmieren in Prolog. 

Springer, 1994. 142 

[Ger91] Uwe Gerlach. Das Transputerbuch: der Einstieg in die Welt der Transputer. 

Markt & Technik, 1991. 

[GR83] Adele Goldberg, David Robson. Smalltalk-80 – The Language and its 

Implementation. Addison-Wesley, 1983. 131 

[Güt85] Rainer Güting. Einführung in UCSD-Pascal. Schwann-Bagel, 1985. 141 

[HM] Albrecht Wöß University of Linz Hanspeter Mössenböck, Markus Löberbauer. 

The Compiler Generator Coco/R (http://ssw.jku.at/coco/). 117 

[HMM97] Robert Harper, David MacQueen, Robin Milner. Standard ML. Technischer 

Bericht ECS–LFCS–86–2, Mit Press, 1997. 142 

[Hum92] Robert L. Hummel. Die Intel-Familie: technisches Referenzhandbuch für 

den 80x86 und 80x87. TLC The Learning Companie, 1992. 

[Int94] SPARC International. The SPARC architecture manual. Prentice Hall, 

1994. 

[JAV] javacc: JavaCCHome (https://javacc.dev.java.net/). 117 

[JL92] Doug Brown John Levine, Tony Mason. Lex and Yacc: UNIX Programming 

Tools (A Nutshell handbook). O’Reilly Media, 1992. 117 

[JW91] Kathleen Jensen, Niklaus Wirth. Pascal user manual and report: ISO 

Pascal standard. Springer, 1991. 12, 131 

[Kop02] Helmut Kopka. L ATEX– eine Einführung. Addison-Wesley, 2002. 5 

[KR90] Brian W. Kernighan, Dennis M. Ritchie. Programmieren in C. Hanser, 

158

Literaturverzeichnis 

1990. 5, 105, 111, 131, 142 

[KV97] Armin Kühnemann, Heiko Vogler. Attributgrammatiken – Eine grundlegende 

Einführung. Vieweg+Teubner, 1997. 121 

[LE89] Henry M. Levy, Richard H. Eckhouse. Computer programming and architecture: 

the VAX. Digital Press, 1989. 

[LY99] Tim Lindholm, Frank Yellin. The Java Virtual Machine Specification. 

Addison-Wesley, 1999. 141 

[LYP] The LEX & YACC Page (http://dinosaur.compilertools.net/). 117 

[MB92] Tony Mason, Doug Brown. lex & yacc. O’Reilly & Associates Inc., 1992. 

111 

[Mot91] Motorola. M68000: 8-/16-/32-bit microprocessors user’s manual. 

Prentice-Hall, 1991. 

[OT97] Peter W. O’Hearn, Robert D. Tennent. ALGOL-Like Languages. 

Birkhäuser, 1997. 12 

[Pau96] Laurence C. Paulson. ML for the Working Programmer. Cambridge 

University Press, 1996. 142 

[Po96] John Peterson, other. Report on the Programming Language Haskell – 

Version 1.3. Technischer Bericht, University of Glasgow, 1996. 131, 142 

[SAB] SableCC (http://sablecc.org/). 117 

[Sch08] Uwe Schöning. Theoretische Informatik kurz gefaßt. Spektrum Akademischer 

Verlag, 2008. 36, 46, 118 

[Thi97] Peter Thiemann. Grundlagen der funktionalen Programmierung. Teubner, 

1997. 129 

[WG92] Niklaus Wirth, Jürg Gutknecht. Project Oberon – The Design of an 

Operating System and Compiler. Addison-Wesley, 1992. 137 

[Wir86] Niklaus Wirth. Compilerbau. Teubner, 1986. 

[Wir97] Niklaus Wirth. Programmieren in Modula-2. Springer, 1997. 6, 131, 142 

[WM96] Reinhard Wilhelm, Dieter Maurer. Übersetzerbau – Theorie, Konstruktion, 

Generierung. Springer, 1996. i, 10, 23, 37, 88, 110, 111, 113, 142 

[WMW85] Gerhard Goos William M. Waite. Compiler Construction. Springer- 

Verlag GmbH, 1985. 

159

Vorlesungsskript - Institut für Programmierung und Reaktive Systeme

Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.

Template löschen?

Als Template speichern?