Sprachübersetzer, T-Diagramme, Compiler, Scanner und Parser

Transkript

1 Sprachübersetzer, T-Diagramme, Compiler, Scanner und Parser Prof.Dr.Christian Wagenknecht mit Beiträgen von Herrn Dr.Michael Hielscher Prof.Dr.Chr. Wagenknecht Formale Sprachen und Automaten 1/44

2 Compiler Begriff Definition Programme, die je ein Wort (Programm) einer Quellsprache Q in ein zugehöriges Wort (Programm) einer Zielsprache Z überführen bzw. übersetzen, nennt man Compiler, genauer: Q Z-Compiler. Aufgabe eines Compilers Wofür braucht man einen Compiler? Programme in Maschinencode (klassisch: Z = Maschinencode) zu schreiben ist sehr schwierig und aufwendig (gigantische Mengen an Code). Komplexere Maschinencode-Programme sind für Menschen schwer lesbar / wartbar. Es schleichen sich schnell Fehler ein, die erst zur Laufzeit (wenn überhaupt) entdeckt werden. Prof.Dr.Chr. Wagenknecht Formale Sprachen und Automaten 2/44

3 Compiler Begriff Definition Programme, die je ein Wort (Programm) einer Quellsprache Q in ein zugehöriges Wort (Programm) einer Zielsprache Z überführen bzw. übersetzen, nennt man Compiler, genauer: Q Z-Compiler. Aufgabe eines Compilers Wofür braucht man einen Compiler? Programme in Maschinencode (klassisch: Z = Maschinencode) zu schreiben ist sehr schwierig und aufwendig (gigantische Mengen an Code). Komplexere Maschinencode-Programme sind für Menschen schwer lesbar / wartbar. Es schleichen sich schnell Fehler ein, die erst zur Laufzeit (wenn überhaupt) entdeckt werden. Prof.Dr.Chr. Wagenknecht Formale Sprachen und Automaten 2/44

4 Interpreter Begriff Definition Interpreter gehen anders vor als Compiler: Das vorgelegte Programm wird nicht vollständig übersetzt, sondern portionsweise analysiert, in eine zugehörige Folge von Prozessorinstruktionen übertragen und ausgeführt. Anwendung Programmiersprachen wie Basic, PHP, Perl und Python besitzen Interpreter. Es gibt sehr viele Skriptsprachen (Sprachen für kleinere Einsatzbereiche), auch in Form von Kommandozeilen-Interpretern (z.b. Windows PowerShell). Prof.Dr.Chr. Wagenknecht Formale Sprachen und Automaten 3/44

5 Compiler vs. Interpreter Langsamer? Übung Man hört immer wieder das Argument, dass Programme in Interpretersprachen typischerweise langsamer laufen als die entsprechenden Programme in Compilersprachen. Stimmt das und wenn ja warum? (Schließen Sie Zyklus-Strukturen in Ihre Betrachtung ein.) Prof.Dr.Chr. Wagenknecht Formale Sprachen und Automaten 4/44

6 Compiler vs. Interpreter Interpretation Übung Kommen wir auch ganz ohne Interpretation aus? Ein vollständiges Programmiersystem kommt nicht ohne Interpretation durch den Prozessor aus. Gleichgültig wie viele Übersetzungsschritte durch Anwendung diverser Compiler auf den Quelltext bzw. auf erzeugte Programme in Zwischensprachen stattgefunden haben, muss das Programm in Zielsprache (z.b. Maschinencode) schließlich doch interpretiert werden. Prof.Dr.Chr. Wagenknecht Formale Sprachen und Automaten 5/44

7 Compiler vs. Interpreter Interpretation Übung Kommen wir auch ganz ohne Interpretation aus? Ein vollständiges Programmiersystem kommt nicht ohne Interpretation durch den Prozessor aus. Gleichgültig wie viele Übersetzungsschritte durch Anwendung diverser Compiler auf den Quelltext bzw. auf erzeugte Programme in Zwischensprachen stattgefunden haben, muss das Programm in Zielsprache (z.b. Maschinencode) schließlich doch interpretiert werden. Prof.Dr.Chr. Wagenknecht Formale Sprachen und Automaten 5/44

8 Compiler vs. Interpreter Pro und Contra Übung Welche Vor- und Nachteile sehen Sie für Interpreter und Compiler? Die Vereinigung der Vorteile beider Systeme führte zu Mischformen: Compiler-Interpreter-Systeme (Interpreter für den Entwurf, Compiler für die Ausführung; z.b. verschiedene Lisp-Systeme), inkrementelle Compiler, die jeweils nur die editierten Programmteile übersetzen, (z.b. Scala; Eclipse: Java) Zwischencode-Interpreter, die ein (vor)compiliertes Programm in einem Zwischencode (z.b. Bytecode) interpretieren und damit eine virtuelle Maschine repräsentieren, und Just-in-time-Compiler, die eine Übersetzung in Maschinencode zur Laufzeit (also gerade noch rechtzeitig ) vornehmen. Prof.Dr.Chr. Wagenknecht Formale Sprachen und Automaten 6/44

9 Compiler vs. Interpreter Pro und Contra Übung Welche Vor- und Nachteile sehen Sie für Interpreter und Compiler? Die Vereinigung der Vorteile beider Systeme führte zu Mischformen: Compiler-Interpreter-Systeme (Interpreter für den Entwurf, Compiler für die Ausführung; z.b. verschiedene Lisp-Systeme), inkrementelle Compiler, die jeweils nur die editierten Programmteile übersetzen, (z.b. Scala; Eclipse: Java) Zwischencode-Interpreter, die ein (vor)compiliertes Programm in einem Zwischencode (z.b. Bytecode) interpretieren und damit eine virtuelle Maschine repräsentieren, und Just-in-time-Compiler, die eine Übersetzung in Maschinencode zur Laufzeit (also gerade noch rechtzeitig ) vornehmen. Prof.Dr.Chr. Wagenknecht Formale Sprachen und Automaten 6/44

10 Zeichenroboter Sprache ZR Einleitung Zeichenroboter Unsere Quellsprache ZR ist die Sprache eines imaginären Zeichenroboters. Wir haben die Vorstellung, dass unser Roboter einen kleinen Zeichenstift besitzt. Dieser Stift ist so angebracht, dass der Roboter bei seinen Vorwärtsbewegungen eine Spur (als Stiftstrich) hinterlässt. Beispiele in der Sprache ZR: VW 50 RE 270 RE 45 WH 2 [VW 100] WH 4 [VW 100 RE 100] WH 36 [WH 4 [VW 100 RE 90] RE 10] Prof.Dr.Chr. Wagenknecht Formale Sprachen und Automaten 7/44

11 Zeichenroboter Sprache ZR Sprachelemente Zeichenroboter Beschreibung der Sprachelemente von ZR: VW n bedeutet, dass sich der Roboter n Schritte vorwärts bewegt. RE n lässt ihn eine Rechtsdrehung um n Grad vollführen. STIFT n bestimmt die Strichstärke n des Stiftes bis zur nächsten Veränderung. FARBE f legt die Farbe (rot, blau, grün, gelb, schwarz) fest. WH n [...] führt dazu, dass die mit Pünktchen symbolisierte Anweisungsfolge n-mal hintereinander ausgeführt wird (Wiederholung). Prof.Dr.Chr. Wagenknecht Formale Sprachen und Automaten 8/44

12 Zeichenroboter Sprache ZR Beispiel Zeichenroboter Beispiel Damit lassen sich ZR-Programme formulieren, wie beispielsweise WH 10 [WH 36 [VW 10 RE 10] RE 40], dessen Interpretation folgendes Ergebnis liefert: Prof.Dr.Chr. Wagenknecht Formale Sprachen und Automaten 9/44

13 Zeichenroboter Sprache ZR Übung Zeichenroboter Beispiel Geben Sie für die nachfolgenden drei Grafiken je ein zugehöriges ZR-Programm an. VW n Roboter n Schritte vorwärts bewegen RE n Rechtsdrehung um n Grad vollführen WH n [...] die mit Pünktchen symbolisierte Anweisungsfolge wird n-mal hintereinander ausgeführt. Prof.Dr.Chr. Wagenknecht Formale Sprachen und Automaten 10/44

14 Zeichenroboter Sprache ZR Übersetzer/Interpreter für ZR ZR interpretieren Suche nach einem geeigneten Verarbeitungsprogramm für ZR-Programme führt zu Turtle-Geometrie-Komponente (TG) der Programmiersprache LOGO oder Python TG-Turtle ist ebenfalls ein Zeichenroboter (eine Art Schildkröte mit einem Stift am Bauch) Es wäre also durchaus möglich, eine ZR TG-Übersetzung anzustreben, um den Vorteil der mit LOGO zur Verfügung stehenden TG-Interpretation auszunutzen. (insbes., wenn es um die dynamische Entw. der Grafik geht) Prof.Dr.Chr. Wagenknecht Formale Sprachen und Automaten 11/44

15 Zeichenroboter Sprache ZR Übersetzer/Interpreter für ZR ZR interpretieren Grafische Darstellungen, die mit Wörtern einer Sprache (also textuell) beschrieben werden: SVG, PostScript (PS) und PDF. Vorteil von PDF : mit dem Adobe Reader steht ein weit verbreiteter Interpreter (Renderer) kostenlos zur Verfügung Nachteil von PDF : Format ist für den Menschen nicht lesbar Wir wollen einen ZR PDF Compiler entwickeln. Prof.Dr.Chr. Wagenknecht Formale Sprachen und Automaten 12/44

16 Modellierung von Übersetzungsprozessen T-Diagramme Modellierung des Compilationsprozesses mit T-Diagrammen T-Diagramme wurden von Bratman entwickelt und von McKeeman, Horning und Wortman zur grafische Darstellung von Übersetzungsprozessen, insbes. Bootstrapping in XPL, 1970 erstmalig verwendet. Sie wurden in Europa von Kerner (1990) und anderen aufgegriffen. Watt und Brown (2000) verwenden hierfür Tombstone-Darstellungen (tombstone = Grabstein), die auch ein bisschen wie Bäckermützen aussehen. Der Name dieser Diagramme rührt von ihrer Grundform her: T. Prof.Dr.Chr. Wagenknecht Formale Sprachen und Automaten 13/44

17 Modellierung von Übersetzungsprozessen T-Diagramme T-Diagramme bestehen aus 3 Grundelementen, die zu Diagrammen zusammengesetzt werden: Prof.Dr.Chr. Wagenknecht Formale Sprachen und Automaten 14/44

18 Modellierung von Übersetzungsprozessen Übung Stellen Sie die Abarbeitung eines Racket-Programms durch einen Racket-Interpreter mit Hilfe eines T-Diagramms dar. Entwickeln Sie ein T-Diagramm für die Übersetzung eines Java-Programms in ByteCode und dessen anschließende Interpretation. Prof.Dr.Chr. Wagenknecht Formale Sprachen und Automaten 15/44

19 Modellierung von Übersetzungsprozessen Cross-Compiler Compiler können auch verwendet werden, um eine ausführbare Datei für ein anderes System zu erzeugen (etwa für Handys). Man bezeichnet diese Compiler als Cross-Compiler. Prof.Dr.Chr. Wagenknecht Formale Sprachen und Automaten 16/44

20 Modellierung von Übersetzungsprozessen Cross-Compiler Man kann Cross-Compiler auch einsetzen, um den Compiler selbst auf eine neue Hardwareplattform zu portieren. Angenommen wir wollen folgenden Compiler herstellen: Annahme: Es gibt noch keinen einzigen Compiler für dieses System. Frage: Wie würden Sie den C++ Alpha Compiler entwickeln? Prof.Dr.Chr. Wagenknecht Formale Sprachen und Automaten 17/44

21 Modellierung von Übersetzungsprozessen Cross-Compiler Wir schreiben einen C++ Compiler für Alpha in der Hochsprache C++. Wir können diesen mit einem Werkzeug wie GCC etwa auf einer Linux Maschine übersetzen lassen: Prof.Dr.Chr. Wagenknecht Formale Sprachen und Automaten 18/44

22 Modellierung von Übersetzungsprozessen Cross-Compiler Nun können wir unseren C++ Quelltext erneut übersetzen - mit dem gerade erzeugten Compiler. Prof.Dr.Chr. Wagenknecht Formale Sprachen und Automaten 19/44

23 Modellierung von Übersetzungsprozessen Cross-Compiler Nun haben wir einen echten C++ Compiler der auf Alpha CPU s läuft und auch ausführbare Dateien für diese Maschine erzeugt. Prof.Dr.Chr. Wagenknecht Formale Sprachen und Automaten 20/44

24 Modellierung von Übersetzungsprozessen Bootstrapping Um einen S M-Compiler (in M) herzustellen, beginnen wir beispielsweise mit einem C-Programm für S M. Dieses kann mit Hilfe eines allgemein verfügbaren C-Compilers in das gewünschte Zielprogramm compiliert werden: Prof.Dr.Chr. Wagenknecht Formale Sprachen und Automaten 21/44

25 Modellierung von Übersetzungsprozessen Bootstrapping Natürlich ist es auch möglich, den S M-Compiler selbst in S zu schreiben (wenn S hinreichend komplex ist). Dann kann dieser Compiler mit dem (gerade hergestellten) S M-Compiler in M übersetzt werden: Prof.Dr.Chr. Wagenknecht Formale Sprachen und Automaten 22/44

26 Modellierung von Übersetzungsprozessen Bootstrapping Nun können wir den in S geschriebenen S M-Compiler verwenden, um Spracherweiterungen von S zu S per Hand in S zu programmieren. Nach einer entsprechenden Compilation erhalten wir einen S M-Compiler in M. Wir können nun diesen wieder verwenden, um einen S M-Compiler in M zu entwickeln usw. Prof.Dr.Chr. Wagenknecht Formale Sprachen und Automaten 23/44

27 Modellierung von Übersetzungsprozessen Bootstrapping Das Verfahren kann man weiter fortsetzen. Da es in jedem Schritt auf Compiler zurückgreift, die im vorhergehenden Schritt quasi mit aufgestockten Bordmitteln erzeugt wurden, nennt man das Verfahren Bootstrapping. Der Begriff wird auch gern in Beziehung zu Baron von Münchhausen (Lügenbaron, ) gebracht, der sich (samt Pferd) am eigenen Zopf aus dem Sumpf gezogen haben soll. Man sollte jedoch immer gut Sicherungskopien von älteren Versionen seines Compilers aufheben, wie eine Geschichte aus der OpenSource Gemeinde zeigte. Prof.Dr.Chr. Wagenknecht Formale Sprachen und Automaten 24/44

28 Modellierung von Übersetzungsprozessen T-Diagramme für ZR PDF Die Abbildung zeigt ein Diagramm für den ZR PDF -Übersetzungsprozess mit anschließender Interpretation der entstehenden PDF-Datei: Prof.Dr.Chr. Wagenknecht Formale Sprachen und Automaten 25/44

29 Modellierung von Übersetzungsprozessen ZR PDF Problem: PDF ist nicht so leicht zu schreiben :-( Der direkte Weg von ZR zu PDF scheint sehr kompliziert zu sein. Folglich: wir wollen kein PDF selber schreiben. Was können wir tun? Prof.Dr.Chr. Wagenknecht Formale Sprachen und Automaten 26/44

30 Modellierung von Übersetzungsprozessen ZR PS PDF Wir verwenden eine Zwischensprache PostScript, für die es zahlreiche Compiler in andere Sprachen wie etwa PDF gibt. Ein solcher Übersetzer ist PS2PDF, der in GhostScript enthalten ist: Prof.Dr.Chr. Wagenknecht Formale Sprachen und Automaten 27/44

31 Modellierung von Übersetzungsprozessen ZR PS PDF Es ergibt sich eine zweistufige Übersetzung (multi-stage translation; multi-stage = mehrstufig/phasig), nämlich von ZR in PS (1. Stufe) und schließlich von PS in PDF (2. Stufe). Mehrstufige Übersetzungen finden häufig unbewusst im Hintergrund statt. So übersetzt ein C++ Compiler zunächst in OBJ-Dateien und linkt diese später zu einer ausführbaren Datei zusammen. Was ist eigentlich PostScript? Eine stapelorientierte Programmiersprache zur Beschreibung von Dokumenten, die im professionellem Druck eingesetzt wird. Für Menschen gut lesbare Sprache, bei der die Operatoren (Funktionen) den Operanden (Argumenten) nachfolgen (post). Tutorial Prof.Dr.Chr. Wagenknecht Formale Sprachen und Automaten 28/44

32 PostScript Aufbau eines PostScript Dokuments Aufbau Um einem PostScript Interpreter klar zu machen, dass es sich um ein PostScript Dokument handelt, wird ein spezieller Kommentar als Kopf (Header) verwendet: %!PS-Adobe-2.0 Nun können wir den eigentlichen Inhalt des Dokuments programmieren. Dazu steht uns eine große Anzahl von vorgefertigten Funktionen zum Zeichnen und zum Ausgeben von Text zur Verfügung. Beispiel für eine einfache schwarze Line: setrgbcolor 0 0 moveto lineto stroke Aufbau: x y moveto x y lineto stroke Prof.Dr.Chr. Wagenknecht Formale Sprachen und Automaten 29/44

33 PostScript Aufbau eines PostScript Dokuments Beispiel: eigene Funktion zum Zeichnen eines Rechtecks definieren /rechteck { /hoehe exch def %Parameter werden in umgekehrter /breite exch def %Reihenfolge vom Stack geholt. /y1 exch def /x1 exch def /x2 x1 breite add def %wir addieren die Breite /y2 y1 hoehe add def %wir addieren die Hoehe x1 y1 moveto %Stift an die Startposition stellen x2 y1 lineto x2 y2 lineto x1 y2 lineto x1 y1 lineto stroke %jetzt alle Linien zeichnen } def %Funktion rechteck definieren rechteck rechteck Prof.Dr.Chr. Wagenknecht Formale Sprachen und Automaten 30/44

34 Scanner und Parser Aufbau eines Compilers Aufbau eines Compilers Klassisch teilt sich die Aufgabe eines Compilers in zwei Phasen: Analysephase und Synthesephase. Wir werden uns zunächst nur mit der Analysephase beschäftigen. Prof.Dr.Chr. Wagenknecht Formale Sprachen und Automaten 31/44

35 Scanner und Parser Aufbau eines Compilers Aufbau eines Compilers Moderne Compiler verwenden meist mehr als 2 Phasen. Es folgen noch Phasen für Codeoptimierung, Typechecking und vieles mehr. 1 die lexikalischer Analyse (Scanner) 2 die syntaktische Analyse (Parser) 3 die Zwischencodegenerierung (AST) 4 die semantische Analyse 5 die Code-Optimierung 6 die Speicherplatzvergabe 7 die Zielcodegenerierung Nur die letzte Phase (Zielcodegenerierung) ist maschinenabhängig. Prof.Dr.Chr. Wagenknecht Formale Sprachen und Automaten 32/44

36 Scanner und Parser ZR PS-Compiler ZR PS-Compiler Wir wollen uns nun der Entwicklung des ZR PS-Compiler aus dem T-Diagramm zuwenden. Natürlich müssen Quell- und Zielsprache bestimmt werden, bevor konkrete Übersetzungsregeln formuliert werden können. Für den Analyseteil des Compilers beschäftigen wir uns nur mit der Quellsprache, die wir durch eine entsprechende Grammatik definieren müssen. Prof.Dr.Chr. Wagenknecht Formale Sprachen und Automaten 33/44

37 Scanner und Parser ZR PS-Compiler Übung Entwickeln Sie eine Grammatik (in BNF) für die Sprache des Zeichenroboters. Beispiele in ZR: VW 50 RE 270 RE 45 WH 2 [VW 100] WH 4 [VW 100 RE 90] WH 36 [VW 10 RE 10] WH 8 [WH 4 [VW 50 RE 90] RE 45] Prof.Dr.Chr. Wagenknecht Formale Sprachen und Automaten 34/44

38 Scanner und Parser ZR PS-Compiler Grammatik für die Sprache ZR G = (N, T, P, s) N = {Programm, Anweisungen, Anweisung, Farbwert, Zahl, Ziffern, Ziffer, ErsteZiffer} T = {WH, [, ], FARBE, RE, STIFT, VW, blau, gelb, gruen, rot, schwarz, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9} P = {Programm Anweisungen Anweisungen Anweisung Anweisungen ε Anweisung WH Zahl [ Anweisungen ] FARBE Farbwert RE Zahl STIFT Zahl VW Zahl Prof.Dr.Chr. Wagenknecht Formale Sprachen und Automaten 35/44

39 Scanner und Parser ZR PS-Compiler Grammatik für die Sprache ZR Farbwert blau gelb gruen rot schwarz Zahl ErsteZiffer Ziffern Ziffern Ziffer Ziffern ε Ziffer ErsteZiffer } s = Programm Prof.Dr.Chr. Wagenknecht Formale Sprachen und Automaten 36/44

40 Scanner und Parser Aufbau der Analysephase Aufbau der Analysephase Die Analysephase gliedert sich in 2 Teile: Scanner und Parser. Pipeline: dem Scanning folgt das Parsing. Der Scanner leistet eine hilfreiche Vorarbeit in Form einer Tokenliste (auch Tokenstrom genannt). Token sind also syntaktische Elementarbausteine. Prof.Dr.Chr. Wagenknecht Formale Sprachen und Automaten 37/44

41 Scanner und Parser Der Scanner Der Scanner Der Scanner liest aus dem Zeichenstrom (Eingabewort) und tastet diesen ab (to scan = abtasten). Er erstellt die Elementarbausteine (Token), indem er einzelne Zeichen zu einem Tokenklasse-Lexem-Paar gruppiert. Jedes erstellte Token wird der Tokenliste angehängt, bis das gesamte Eingabewort eingelesen wurde, oder ein Fehler aufgetreten ist. Ein Lexem ist eine zur betrachteten Tokenklasse gehörende Zeichenkette als Teil des Analysewortes. Prof.Dr.Chr. Wagenknecht Formale Sprachen und Automaten 38/44

42 Scanner und Parser Der Scanner Der Scanner Beispiele für typische Tokenklassen sind: Schlüsselwort (für reservierte Befehlsworte), Bezeichner (für Variablennamen), Zahl, Zuweisungsoperator (für =), linkeklammer, rechteklammer und Begrenzer (für ;). Für das Festlegen von Tokenklassen gibt es keine Definition oder Vorschrift, es ist eher eine Erfahrungsentscheidung. Typischerweise werden die (regulären) Typ-3-Anteile der Grammatik als Tokenklassen herausgegriffen. Prof.Dr.Chr. Wagenknecht Formale Sprachen und Automaten 39/44

43 Compiler und Interpreter Sprache eines Zeichenroboters Modellierung Scanner und Parser Scanner und Parser Der Scanner Der Scanner Das Arbeitsergebnis des Scanners ist die Tokenliste. Fu r ein Eingabewort in ZR wie WH 4 [VW 100 RE 90] ko nnte etwa folgende Tokenliste entstehen: ((Wiederhole, WH ),(Zahl, 4 ),(KlammerAuf, [ ), (Vor, VW ),(Zahl, 100 ),(Rechts, RE ), (Zahl, 90 ),(KlammerZu, ] )) Wie man im Beispiel sehen kann, gibt es pro Tokenklassen unterschiedlich viele passende Lexeme. Im Extremfall gibt es nur eins, wie bei Wiederhole, Rechts oder KlammerAuf. Prof.Dr.Chr. Wagenknecht Formale Sprachen und Automaten 40/44

44 Scanner und Parser Der Scanner Arbeitsweise des Scanners Die Tokenerkennung durch den Scanner erfordert ein Programm, das der jeweils definierten syntaktischen Einheit entspricht und wie folgt arbeitet: 1 Nimm einen bestimmten Bearbeitungszustand z 0 ein. 2 Lies das nächste Zeichen a und nimm in Abhängigkeit von a einen (nicht notwendigerweise anderen) Zustand z i ein. 3 Stopp, falls die Zeichenfolge vollständig abgetastet wurde, ansonsten gehe nach 2. Dies ist eine informelle Beschreibung der Arbeit abstrakter Zustandsautomaten, die wir endliche Automaten nennen und in der nächsten Vorlesung thematisieren werden. Ein Scanner ergibt sich dann als Komposition endlicher Automaten mit verschiedenen Anfangszeichen. Prof.Dr.Chr. Wagenknecht Formale Sprachen und Automaten 41/44

45 Scanner und Parser Der Parser Der Parser Als Nächstes kommt der Parser zum Einsatz. Durch die Bereitstellung des Tokenstroms braucht er sich nicht mehr um die Analyse der Lexeme zu kümmern, die dem jeweiligen Token zugeordnet wurden. Der Parser versteht sie als Terminale einer reduzierten Grammatik, die für ZR als G angegeben werden kann. Prof.Dr.Chr. Wagenknecht Formale Sprachen und Automaten 42/44

46 Scanner und Parser Der Parser reduzierten Grammatik G G = (N, T, P, s ) N = {Programm, Anweisungen, Anweisung} T = {WH, [, ], FARBE, RE, STIFT, VW, Zahl, Farbwert} P = {Programm Anweisungen Anweisungen Anweisung Anweisungen ε Anweisung WH Zahl [ Anweisungen ] FARBE Farbwert RE Zahl STIFT Zahl VW Zahl } s = Programm Prof.Dr.Chr. Wagenknecht Formale Sprachen und Automaten 43/44

47 Scanner und Parser Der Parser Arbeitsweise des Parsers Um später einen Compiler erstellen zu können, müssen wir auch die Arbeitsweise des Parsers grundlegend verstehen. Es gibt verschiedene Varianten wie ein Parser arbeiten kann. Eine haben wir bereits bei der Linksableitung vom Spitzensymbol s kennengelernt: Top-Down-Analyse. Auch eine Bottom-Up-Analyse ist denkbar. Beide Varianten finden in der Praxis Verwendung. Auch für den Parser werden wir einen Automaten angeben können, der dessen Arbeitsweise beschreibt. Prof.Dr.Chr. Wagenknecht Formale Sprachen und Automaten 44/44