Compilerbau. Vorlesungsskript. Prof. Dr. Ursula Goltz Dr. Thomas Gehrke Dipl.-Inform. Malte Lochau. 11. Mai 2010

Transkript

1 TECHNISCHE UNIVERSITÄT CAROLO-WILHELMINA ZU BRAUNSCHWEIG Vorlesungsskript Compilerbau Prof. Dr. Ursula Goltz Dr. Thomas Gehrke Dipl.-Inform. Malte Lochau 11. Mai 2010 Institut für Programmierung und Reaktive Systeme

2

3 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

4

5 Inhaltsverzeichnis Verzeichnis der Abbildungen Verzeichnis der Tabellen Listings v vii viii 1 Einführung Inhalte und Gliederung Höhere Programmiersprachen Implementierung von Programmiersprachen Interpreter Compiler Virtuelle Maschinen als Zielplattform Umgebung eines Compilers Aufbau eines Compilers Analyse Synthese Front-End, Back-End Läufe Lexikalische Analyse Terminologie Reguläre Sprachen und endliche Automaten Reguläre Sprachen Reguläre Ausdrücke Endliche Automaten Reguläre Definitionen Sieber Fehlerbehandlung Syntaktische Analyse Kontextfreie Grammatiken Kontextfreie Grammatiken Ableitungen Strukturbäume iii

6 Inhaltsverzeichnis Mehrdeutige Grammatiken Konstruktion von Parsern Kellerautomat Top-Down-Syntaxanalyse LL(k)-Grammatiken Transformierung von Grammatiken Erweiterte kontextfreie Grammatiken Fehlerbehandlung bei der Top-Down-Analyse Bottom-Up-Syntaxanalyse LR(k)-Grammatiken Fehlerbehandlung bei der Bottom-Up-Analyse Parser Generatoren Semantische Analyse Attributierte Grammatiken Typüberprüfung Typsysteme Gleichheit von Typausdrücken Typumwandlungen Zwischencode-Erzeugung Abstrakte Keller-Maschinen Syntaxbäume Zwischencode für die Keller-Maschine Befehle zur Steuerung des Kontrollflusses Drei-Adreß-Code Übersetzung von Syntaxbäumen in Drei-Adreß-Code Übersetzung in Drei-Adreß-Code unter Verwendung von attributierten Grammatiken Vergleich der beiden Arten von Zwischencode Literaturverzeichnis 158 iv

7 Verzeichnis der Abbildungen 1.1 Umgebung eines Compilers Phasen eines Compilers Übersetzung einer Zuweisung Parse-Baum der Zuweisung Interaktion zwischen Scanner und Parser Beispiel eines Übergangsgraphen Konstruktion eines NEA zu einem regulärem Ausdruck Beispiel einer NEA-Konstruktion Beispiel zur Potenzmengenkonstruktion DEA mit minimaler Zustandsmenge Beispiel zur Minimalisierung Übergangsgraphen für die Symbole des Beispiels Analyse eines Programmausschnitts Interaktion zwischen Scanner, Parser und restlichem Front-End Beispiel eines Strukturbaums Konstruktion eines Strukturbaums Verschiedene Strukturbäume zu einem Satz Mögliche Strukturbäume des dangling else -Problems Lösung des dangling else -Problems Schema eines Kellerautomaten Konstruktion des Strukturbaums anhand der Ausgabe des Parsers Fehlerhafte Konstruktion eines Strukturbaums für die Eingabe a Transformation in rechtsrekursive Grammatik Beispiel einer regulären Ableitung Übergangsgraphen für arithmetische Ausdrücke Übergangsgraphen für Pascal-Typen Beispiel eines recursive descent-parsers Aufrufgraph einer recursive descent-syntaxanalyse Erzeugung eines Strukturbaums für einen arithmetischen Ausdruck Beispiel eines charakteristischen endlichen Automaten Beispiel eines LR-DEA Struktur einer LR(1)-Parse-Tabelle v

8 Verzeichnis der Abbildungen 3.20 Zustandsmenge des LR-DEA der Grammatik zur Beschreibung der C-Zuweisung aus Beispiel Zustandsmenge des charakteristischen endlichen Automaten mit LR(1)- Items zur Grammatik aus Beispiel Charakteristischer endlicher LR(1)-Automat zur Grammatik aus Beispiel Zustandsmenge des charakteristischen endlichen Automaten mit SLR(1)- Items für die Grammatik aus Beispiel Zustandsmenge des charakteristischen endlichen Automaten mit LALR(1)- Items für die Grammatik aus Beispiel Charakteristischer endlicher LR(1)-Automat zur Grammatik aus Beispiel Beispiel eines attributierten Strukturbaums Synthetische und inherite Attribute Berechnung von Typinformationen im Strukturbaum Attributierter Strukturbaum zur Analyse einer Binärzahl Attributierter Strukturbaum zur Analyse einer Binärzahl mit inheritem Attribut Darstellung der direkten Abhängigkeiten zwischen Attributvorkommen Beispiel eines Abhängigkeitsgraphen Verklebter Abhängigkeitsgraph Semantische Regeln für Beispielsprache Attributierter Strukturbaum für ein Beispielprogramm Attributierter Strukturbaum für ein fehlerhaftes Beispielprogramm Funktion zur Überprüfung, ob zwei Typausdrücke identisch sind Attributierter Strukturbaum einer Zuweisung Attributierter Strukturbaum einer Zuweisung mit Attributabhängigkeiten Attributierter Strukturbaum einer Zuweisung mit Typfehler Einordnung der Zwischencode-Erzeugung Syntaxbaum Konstruktion eines Syntaxbaums aus Postfix-Notation Auswertung eines Postfix-Ausdrucks mit Hilfe eines Stacks Attributierter Strukturbaum mit Zwischencode Attributierter Strukturbaum einer verschachtelten if-anweisung Syntaxbaum mit temporären Namen Syntaxbaum mit Attributen für die Erzeugung von Drei-Adreß-Code. 156 vi

9 Verzeichnis der Tabellen 2.1 Beispiele für Symbole, Muster und Lexeme Übergangsrelation in Tabellenform Reguläre Ausdrücke und die dazugehörigen Symbole und Attributwerte Beispielableitung eines Top-Down-Parsers Beispiel einer Parse-Tabelle Parse-Tabelle für dangling-else-grammatik Für Fehlerbehandlung modifizierte Parse-Tabelle Beispiel einer Ableitung mit Fehlerbehandlung Beispielableitung eines Bottom-Up-Parsers vii

10 Listings NEA nach DEA DEA Minimalisierung Berechnung von FIRST 1 Mengen Berechnung von FOLLOW 1 Mengen Transformation einer linksrekursiven in eine rechtsrekursive Grammatik.. 60 Linksfaktorisierung Konstruktion der Parse Tabelle zu einer Grammatik Deterministische Top Down Analyse mit Parse Tabelle Konstruktion der FIRST und FOLLOW Mengen einer ELL(1) Grammatik 69 Beispiel eines recursive descent Parsers LR DEA Konstruktion Algorithmus LR(1) GEN Konstruktion der LR(1) action Tabelle LR(1) Parse Algorithmus Konstruktion der SLR(1) action Tabelle Ueberpruefung ob zwei Typausdruecke identisch sind viii

11 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-

12 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 1 Mnemonik ist die Kunst, das Gedächtnis durch Hilfsmittel zu unterstützen. 2

13 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 Interpreter EinInterpreterI L zureinerprogrammiersprachelisteinprogramm,dasalseingabe einprogrammp L dersprachelundeineeingabefolgeeerhältundeineausgabefolge a errechnet. Da bei der Interpretation von p L auch Fehler auftreten können, läßt sich die Funktionalität des Interpreters darstellen als I L : L D D {error}, wenn sowohl Eingabe- wie auch Ausgabedaten aus einem gemeinsamen Bereich D stammen. Die Ausführung des Programms p L mit Eingabefolge e und Ausgabefolge a ist durch die Gleichung I L (p L,e) = a beschrieben. Die Arbeitsweise eines Interpreters ist gekennzeichnet durch eine gleichzeitige Bearbeitung des Programms p L 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 p L verwenden 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 p L 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

14 1 Einführung Wir nennen unsere zu übersetzende Sprache L im folgenden Quellsprache. Die Übersetzung besteht in der Überführung eines Programms p L der Quellsprache in ein Programm p M, wobei M die Maschinen- oder die Assemblersprache eines konkreten oder abstrakten Rechners ist. Wir nennen p M Zielprogramm und folglich M die Zielsprache des Übersetzers. Nach der Übersetzung wird das erzeugte Programm p M zur Laufzeit mit der Eingabefolge e ausgeführt. Dabei gehen wir davon aus, daß p M mit der Eingabe e die Ausgabe a erzeugt, wenn ein Interpreter für L mit I L (p L,e) = a dieselbe Ausgabe erzeugt. Wenn wir die Maschine, deren Maschinensprache unsere Zielsprache M ist, als Interpreter I M für M auffassen, so muß gelten: wenn I L (p L,e) = a,dann I M (p M,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 p M entdeckt werden 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

15 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.#def ine in C [KR90]), um die Generierung zusätzlicher Befehle zur Fehlersuche oder um das Einfügen weiterer Quelltexte (z.b. \include in L A TEX[Kop02]) handeln. Diese Modifikationen des Quelltextes werden von einem sogenannten Präprozessor 5

16 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

17 1.5 Aufbau eines Compilers Quellprogramm lexikalische Analyse Analyse syntaktische Analyse semantische Analyse Codeerzeugung Symboltabellenverwaltung Fehlerbehandlung Zwischencodeerzeugung Codeoptimierung Synthese Zielprogramm 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. 1.5 Aufbau eines Compilers 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 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

18 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 id 1 ersetzt worden, initial durch id 2 und rate durch id 3 ). 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

19 1.5 Aufbau eines Compilers position := initial + rate * 60 lexikalische Analyse id 1 := id 2 +id 3 60 syntaktische Analyse := id 1 + id 2 * id 3 60 semantische Analyse := id 1 + id * 2 id 3 inttoreal Zwischencode-Erzeugung temp1 := inttoreal(60) temp2 := id3 * temp1 temp3 := id2 + temp2 id1 := temp3 Code-Optimierung Symboltabelle position... initial... rate... 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 Abbildung 1.3: Übersetzung einer Zuweisung. 9

20 1 Einführung Zuweisung Bezeichner := Ausdruck position Ausdruck + Ausdruck Bezeichner Ausdruck * Ausdruck initial Bezeichner rate Zahl 60 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 [WM96] synonym verwendet. 10

21 1.5 Aufbau eines Compilers 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ß 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

22 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) 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 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

23 1.5 Aufbau eines Compilers 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

24 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. Symbol Quellprogramm Scanner Parser nächstes Symbol anfordern Symboltabelle Abbildung 2.1: Interaktion zwischen Scanner und Parser.

25 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. 2.2 Reguläre Sprachen und endliche Automaten 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 , A195, 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

26 2 Lexikalische Analyse 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 Li Positiver Abschluß: L + := i=1 Li 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 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 L 1,L 2 reguläre Sprachen, so sind auch L 1 L 2, L 1 L 2 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 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

27 2.2 Reguläre Sprachen und endliche Automaten reg(σ), ε reg(σ), für jedes a Σ ist a reg(σ), falls r 1,r 2 reg(σ), dann (r 1 r 2 ) reg(σ),(r 1 r 2 ) reg(σ) und (r 1 ) 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((r 1 r 2 )) = L(r 1 ) L(r 2 ), L((r 1 r 2 )) = L(r 1 )L(r 2 ), L((r 1 ) ) = (L(r 1 )) 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} (ab) 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

28 2 Lexikalische Analyse 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. hatdieniedrigstepriorität( (a b) cvs.a b c )undistebenfallslinksassoziativ. 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) 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 EinnichtdeterministischerendlicherAutomat(NEA) ist eintupelm = (Σ,Q,,q 0,F), wobei Σ endliches Alphabet (das Eingabealphabet), Q endliche Menge (von Zuständen), q 0 Q (der Anfangszustand), F Q (die Menge der Endzustände) und Q (Σ {ε}) Q (die Übergangsrelation) ist. Definition 5 Sei M = (Σ,Q,,q 0,F) ein NEA. Ein Paar (q,w),q Q,w Σ heißt Konfiguration von M, (q 0,w) heißt Anfangskonfiguration, (q f,ε) mit q f F Endkonfiguration. Die Schritt-Relation ist eine binäre Relation M (Q Σ ) (Q Σ ), definiert durch 18

29 2.2 Reguläre Sprachen und endliche Automaten (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 Σ (q 0,w) M (q f,ε), q f 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 q 0 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 erkenntdie 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ÜbergangsgraphinAbbildung2.2stellt einennea dar, der diesprachel((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

30 2 Lexikalische Analyse a a b b b Abbildung 2.2: Beispiel eines Übergangsgraphen. Zustand / Eingabe a b ε 0 {0,1} {0} {2} {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,r 1,r 2 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

31 2.2 Reguläre Sprachen und endliche Automaten 1 r 2 q r p r q p q p r 1 (A) r 2 r 1 r 2 q p r 1 q q1 r 2 p ε q r p q ε q1 q2 ε p r (K) (S) ε (r) q p q r p (KL) Abbildung 2.3: Konstruktion eines NEA zu einem regulärem Ausdruck. a(a 0) 0 1 a (a 0) (a 0) 0 a 2 ε 3 4 ε 1 ε (K) (S) ε a a ε ε 1 ε (KL),(A) ε Abbildung 2.4: Beispiel einer NEA-Konstruktion. 21

32 2 Lexikalische Analyse 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,Σ,,q 0,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,Σ,,q 0,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) = q Sε FZ(q). Definition 8 Sei M = (Q,Σ,,q 0,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(q 0 ), F = {S Q S F } und δ(s,a) = ε FZ({p (q,a,p) fürq S}) für a Σ,S Q. 22

33 2.2 Reguläre Sprachen und endliche Automaten 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,Σ,,q 0,F) Ausgabe: DEA M = (Q,Σ,δ,q 0,F ) 1 q 0 := ε FZ(q 0 ); Q := {q 0};\\ 2 marked(q 0) := false; δ := ;\\ 3 while existiert S ǫq and marked(s) = false do 4 marked(s) := true; 5 foreach aǫσ do 6 T := ε FZ({pǫQ (q,a,p)ǫ undq ǫ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