0 Seminar Übersetzung künstlicher Sprachen im SS 2009 Lexikalische Analyse, Lex Karin Pietzonka.
-
Upload
faramond-hensel -
Category
Documents
-
view
107 -
download
0
Transcript of 0 Seminar Übersetzung künstlicher Sprachen im SS 2009 Lexikalische Analyse, Lex Karin Pietzonka.
1
Seminar „Übersetzung künstlicher Sprachen“ im SS 2009
Lexikalische Analyse, Lex
Karin Pietzonka
2
Agenda
Motivation
Lexikalische AnalyseEinordnung
Verfahren
Generierung eines ScannersAnforderungen
Manuelle Generierung
Der Scannergenerator lex
Weitere Scannergeneratoren
Zusammenfassung & Ausblick
3
Motivation
Motivation
Lexikalische AnalyseEinordnung
Verfahren
Generierung eines ScannersAnforderungen
Manuelle Generierung
Der Scannergenerator lex
Weitere Scannergeneratoren
Zusammenfassung & Ausblick
4
Motivation
Compilerbau seit 1952 (Grace Hopper)
Aufgabe:
Quellprogramm Zielprogramm
Wie kommt das Quellprogramm in den Compiler?
Sollen bzw. müssen alle Zeichen verarbeitet / umgewandelt werden?
Wie beginnt die Umwandlung des Quellprogramms?
…
→ lexikalische Analyse
5
Lexikalische Analyse
Motivation
Lexikalische AnalyseEinordnung
Verfahren
Generierung eines ScannersAnforderungen
Manuelle Generierung
Der Scannergenerator lex
Weitere Scannergeneratoren
Zusammenfassung & Ausblick
6
Compiler ist in Phasen gegliedert
Einordnung
Frontend:
Analysiert, strukturiert und prüft den Quelltext auf Fehler
Backend:
Erzeugung des Zielprogramms
7
Aufgaben der lexikalischen Analyse
ScannenEinlesen / Scannen der Eingabezeichen des Quellprogramms mit Hilfe eines Lexers / Scanners
Kommentaren und Leerraum entfernen
Fehlermeldungen zuordnen
Lexikalische Analyse i.e.S.Eingabezeichen nach Mustern absuchen
Zu Lexemen gruppieren
Zuweisung von Token
8
Trennung lexikalische und syntaktische Analyse
Generell ist Zusammenarbeit der lexikalischen und syntaktischen Analyse möglich
Vorteile der TrennungVereinfachung eines Sprachentwurfs
Effizienzverbesserung
Erhöhung der Portabilität
9
Trennung lexikalische und syntaktische Analyse
Häufige Implementierung: Scan on demand
10
Lexikalische Analyse - Verfahren
Motivation
Lexikalische AnalyseEinordnung
Verfahren
Generierung eines ScannersAnforderungen
Manuelle Generierung
Der Scannergenerator lex
Weitere Scannergeneratoren
Zusammenfassung & Ausblick
11
Einstiegsbeispiel
Definition beliebiger Tokenklassen, z. B. Satzbausteine
Lexikalische Analyse sucht nach Mustern, die in Tokenklassen definiert wurden
Ein Mann steigt in sein blaues Auto .
artikel nomen verb präposition pronomen adjektiv nomen punkt
12
Token
Elementarbaustein
<Tokenname, Attributwert>
selbstbestimmt optional, z. B. Zeiger auf Symboltabelle oder Ausprägungen des Token
Token Beispiel Beschreibung
id abcd, Dipl.-Ing., E150d Buchstabe, auf den
Buchstaben/Ziffern folgen
num 3, 26.587, 0 alle Zahlen
comp <, >, =, !=, <=, >= alle Vergleichssymbole
op +, -, /, * die Grundoperatoren
saz (, ), ;, ,, …andere Satzzeichen
(Klammern, Semikolon etc.)
if if das Wort if
else else das Wort else
literal „ Ausgabe“alles, was in
Anführungszeichen steht
op +, -, /, * die Grundoperatoren
13
Reguläre Ausdrücke
( `+` + `-`) ? (0 + 1 + 2 + 3 + 4 + 5 + 6 + 7 + 8 + 9 ) + (, (0 + 1
+ 2 + 3 + 4 + 5 + 6 + 7 + 8 + 9 ) + )?
Basis für die Beschreibung der zu erkennenden Muster
Darstellung einer Kommazahl
Zusammengehörige Abschnitte mit „(…)“
Konkatenation einzelner Teile
„+“ oder „|“: Auswahl der Elemente (vereinigte Menge)
„?“: eine oder keine Wiederholung
„+“: mindestens eine Wiederholung
„*“: beliebig viele Wiederholungen, auch keine
Alternative zu „(`+` + `-`)?“ ist (+| - |ε)
14
Reguläre Sprachen und Definitionen
Reguläre Sprachen:
Sprachen, die sich mit Hilfe von regulären Ausdrücken beschreiben lassen
Reguläre Definitionen:
Um regulären Ausdrücken verständlichere Namen zu geben und Rekursionen zu vermeiden
Definition d → regulärer Ausdruck a (wobei a ∑ und d ∑)∊ ∉
Beispiel: Ziffer → (0 + 1 + 2 + 3 + 4 + 5 + 6 + 7 + 8 + 9)
15
Endliche Automaten
Darstellung regulärer Ausdrücke durch Übergangsdiagramme
Startzustand Zustands-übergang
Endzustand
16
Nichtdeterministischer endlicher Automat (NEA)
NEA unterscheidet sich vom EA dadurch, dass aus einem Zustand mehrere Kanten mit der gleichen Beschriftung in verschiedene Zustände laufen können
17
NEA - EA
Aus jedem NEA lässt sich mit dem Verfahren der Potenzmengenkonstruktion ein EA konstruieren
EA kürzer und schneller
In dem meisten Fällen: erster, intuitiver Entwurf NEA
Umwandlung lohnt sich – mehrfache Nutzung während der lexikalischen Analyse
18
Pattern-Matching
Hauptaufgabe der lexikalischen Analyse: Mustererkennung und Zuordnung von Token
Zuordnung der Token
Wortkennung
Ausblenden bedeutungsloser
Zeichen
19
Worterkennung & Tokenzuordnung
Bedingung: Vordefinierte reguläre Ausdrücke
Zugeordnete Token
Beispiel: EA für „begin“
return (BEGIN);
20
Worterkennung & Tokenzuordnung
Problem: Mehrdeutigkeit
Beispiel: „< = “ ein oder zwei Zeichen?
Lösungen: Longest match
Reservierte Schlüsselwörter
21
Worterkennung & Tokenzuordnung
Reservierte Schlüsselwörter in der Symboltabelle
1
2
3
4
.
.
.
9
10
11
12
Inde
x
const
var
begin
end
.
.
.
odd
abcd
Dipl.-Ing.
E150dS
chlü
ssel
wör
ter
Bez
eich
ner
22
Generierung eines Scanners
Motivation
Lexikalische AnalyseEinordnung
Verfahren
Generierung eines ScannersAnforderungen
Manuelle Generierung
Der Scannergenerator lex
Weitere Scannergeneratoren
Zusammenfassung & Ausblick
23
Anforderungen
Implementierung des Scanners entscheidet, in welcher Form später die Eingabedaten vorliegen müssen
Einfache FragestellungenWas ist ein Wort für meinen Compiler? - z.B. „BeGin“ = „BEGIN“
Unterscheidung von Groß- und Kleinschreibung?
Ist z.B. „Beginnen“ eine ID oder Schlüsselwort BEGIN + ID
Sind Zahlen erlaubt?
Was passiert mit Wörtern, die aus Zahlen und Buchstaben bestehen? - z.B. Farbstoff E150d
Wie werden Wörter mit Bindestrichen behandelt?
Was geschieht mit weiteren Zeichen im Quelltext?
24
Anforderungen
Effizienz Eine effiziente lexikalische Analyse dient der gesamten Kompilierung
Je schneller der Scanner ein klares und eindeutiges Ergebnis liefert, desto schneller können auch von der Syntaxanalyse und den folgende Phasen Ergebnisse erwartet werden
Besonders beim scan on demand ist zügige Bearbeitung erforderlich
25
Manuelle Generierung
Motivation
Lexikalische AnalyseEinordnung
Verfahren
Generierung eines ScannersAnforderungen
Manuelle Generierung
Der Scannergenerator lex
Weitere Scannergeneratoren
Zusammenfassung & Ausblick
26
Manuelle Generierung
Beschreibung der Struktur der Symbole bzw. der Muster
Übergangsdiagramm erstellen
Programm erstellen
Zuordnung von Token
Programm erkennt Symbole / Token
Jeder Zustand erhält Nummer und wird durch Code wiedergegeben
3 Möglichkeiten
27
Manuelle Generierung
Zuordnung von Token
Übergangsdiagramme nacheinander testen
Übergangsdiagramme parallel testen
Ein einziges, zusammengefasstes Übergangsdiagramm
Übergangsdiagramme parallel testen
Übergangsdiagramme nacheinander testen
28
Der Scannergenerator lex
Motivation
Lexikalische AnalyseEinordnung
Verfahren
Generierung eines ScannersAnforderungen
Manuelle Generierung
Der Scannergenerator lex
Weitere Scannergeneratoren
Zusammenfassung & Ausblick
29
Der Scannergenerator lex
Entwickelt in den 70er Jahren
Unix – Standardwerkzeug
Als Ergänzung zum Parser-Generator yacc
Selbst vergleichbar mit einem Compiler, der aus einem lex-Programm ein C-Programm erstellt
VorteileKürzere Entwicklungszeit im Gegensatz zur manuellen Generierung
Besonders für komplizierte und komplexe Probleme geeignet
Durch immer gleichen Aufbau bessere Lesbarkeit und leichte Änderungsmöglichkeiten
Nutzer benötigt keine umfangreichen Programmier- und Pattern-Matching-Kenntnisse
30
Der Scannergenerator lex
Als Eingabe wird ein lex-Programm akzeptiertReguläre Ausdrücke definieren den zu erstellenden Scanner / Lexer
Programmteil in C / Ratfor, welcher Aktionen beschreibt
Lex-Compiler
C-Compiler
a.out
Lex-Programmlex.l lex.yy.c
lex.yy.c a.out
Eingabezeichen Folge von Token
31
lex-Programm
%{
Deklaration
%}
%%
Übersetzungsregeln
%%
Hilfsfunktionen
Optionaler Deklarations- bzw. Definitionsteil
Optionen, Deklarationen von Variablen, manifeste Konstanten
z.B. #define
Zwischen %{…%} unverändert übernommen
Tabelle mit Muster & Aktionen Muster {Aktion}
Muster = regulärer Ausdruck
Aktion = C-Anweisung(en)
Optionale HilfsfunktionenLokale Funktionen, die durch Übersetzungsregeln genutzt und in Aktionen eingesetzt werden
32
lex-Programm
%{#include <stdlib.h>#include „global.h“ int tokenwert = NICHTS; /*Programmglobale Variable, der
ggfs.Zahlenwert zugewiesen wird*/ int zeilennr = 1; /*Programmglobale Variable,
enthaelt immer Nr der aktuellen Eingabezeile*/
%}%%[ \t]+ /*Leer- und Tabzeichen ueberlesen*/\n {return (ZEILENENDE);}[0-9]+{tokenwert = strtol(yytext,NULL,10); return(ZAHL)}
/*strtol wandelt den String aus yytext in eine Zahl um und weist sie tokenwert zu'/
"+" {return (PLUS);}"-" {return (MINUS);}"*" {return (MULT);}"/" {return (DIV);}%%
Beispiel: einfacher Taschenrechner
33
Weitere Scannergeneratoren
Motivation
Lexikalische AnalyseEinordnung
Verfahren
Generierung eines ScannersAnforderungen
Manuelle Generierung
Der Scannergenerator lex
Weitere Scannergeneratoren
Zusammenfassung & Ausblick
34
Weitere Scannergeneratoren
FlexNachfolger von lex
Ermöglicht Nutzung unter Windows
Schnellere und effizientere Implementierung
Tabellengesteuerter Automat in C
Schnittstelle zum Parser-Generator yacc
Rex GMD – Forschungszentrum Informationstechnik in Karlsruhe
Tabellengesteuerter Automat in C
Schnittstelle zum Parser-Generator yacc
Implementierungsmöglichkeiten in Modula-2
GLA, Sable CC, ALEX, COCO, VCC, …
35
Zusammenfassung & Ausblick
Motivation
Lexikalische AnalyseEinordnung
Verfahren
Generierung eines ScannersAnforderungen
Manuelle Generierung
Der Scannergenerator lex
Weitere Scannergeneratoren
Zusammenfassung & Ausblick
36
Zusammenfassung
Aufgaben der lexikalischen AnalyseEinlesen des Quelltextes
Mustererkennung mit Hilfe regulärer Ausdrücke
Tokenzuordnung
Einfache und effiziente Scannererstellung mit Hilfe des Scannergenerators lex
Keine umfangreichen Programmierkenntnisse erforderlich
Erhebliche Erleichterung bei komplexen Problemen
37
Ausblick
Entwicklung hat trotz 60jähriger Entwicklung noch kein Ende
Vielzahl von ScannergeneratorenErweiterung auf unterschiedliche Programmiersprachen
Migrationscompiler, z. B. Umstellung des Toyota-Händlersystems von ROSI-SQL auf C++
Effizienzverbesserung und Kostenreduktionz.B. Übergangstabellenverkleinerung
Ständig neue Erkenntnisse auf anderen Gebieten der Forschung, z.B. Größe und Kapazität von Speichermedien und Verbesserung von Prozessoren
Neue Techniken für den Compilerbau und somit für die lexikalische Analyse
38
Lexikalische Analyse, Lex
Vielen Dank für eure
Aufmerksamkeit!
39
Back-Up
40
Back-Up
Definition – Reguläre Ausdrücke
Definition - EA
Darstellungsformen EA
Eingabepuffer
Probleme
Aufwand & Optimierungsmöglichkeiten
41
Reguläre Ausdrücke
DefinitionSei ∑ ein Alphabet, d. h. eine nicht leere, endliche Menge von Zeichen bzw. Zeichenreihen, die total geordnet sind.
1. Ø ist ein regulärer Ausdruck und bezeichnet die leere Menge.
2. ε ist ein regulärer Ausdruck und bezeichnet das leere Wort, d. h.
die Menge {ε}.
3. a ist ein regulärer Ausdruck und bezeichnet die Menge {a}.
42
Reguläre Ausdrücke
Per Induktion sind folgende Ausdrücke definiertSeien a und b reguläre Ausdrücke, die die Menge A und B beschreiben, dann
a) ist (a + b) bzw. (a | b) ein regulärer Ausdruck und bezeichnet die
Menge A U B (Vereinigung)
b) ist (ab) ein regulärer Ausdruck und bezeichnet die Menge AB
(Konkatenation)
c) ist (a*) ein regulärer Ausdruck und bezeichnet die Menge A*
(Kleen´sche Hülle)
d) Außerdem können Klammern um Ausdrücke gesetzt werden,
ohne dass sich die zugehörige Sprache ändert. Für bessere
Lesbarkeit ist jedoch Klammereinsparung durch definierte
Prioritäten von Vorteil
43
Endliche Automaten
DefinitionEA = (Q, ∑, δ, q0, F)
Q: endliche Menge von Zuständen
∑: endliche Menge von Eingabesymbolen
δ: Q × ∑ → Q Übergangsfunktionen
q0 ∊ Q: Startzustand
F ⊆ Q: Endzustand
Regulärer Ausdruck wird akzeptiert, wenn der EA einen Endzustand erreicht → akzeptierte Sprache
44
Endliche Automaten
DarstellungsformenÜbergangsdiagramm
Tupel EA = (Q, ∑, δ, q0, F)
Übergangstabelle
Zustand/ Übergang
+ - ε Ziffer ,
q0 q1 q1 q1
q1 q2
q2 q2 q3
q3 q4
q4 q4
45
Eingabepuffer
Einlesen wird dadurch erschwert, dass oft über das nächste Lexem hinausgeblickt werden muss (Lookahead)
Beschleunigung durch Eingabepuffer2 separate Puffer der Größe N
Umf 2= * Rad*Pi eof
lexemeBeginforward
46
Probleme
Probleme, wie z.B. Mehrdeutigkeiten oder Beschleunigung des Einleseprozesses können gelöst werden
Großes Problem: RechtschreibungBeispiel: „begni“ als Bezeichner identifiziert
und bekommt das Token ID anstatt BEGIN zugewiesen
47
Probleme
Lösung: Recovery – Aktionen
Beispiel: Panic Mode RecoveryEs werden nacheinander so lang Zeichen gelöscht, bis ein bekanntes, einwandfreies Token gefunden wird
Weitere TechnikenLöschen eines überflüssigen Zeichens
Einfügen eines fehlenden Zeichens
Ersetzen eines Zeichens
Tausch benachbarter Zeichen: „begni“ → „begin“
48
Aufwand
Kaum Studien, die den Aufwand bzw. die Kosten genau bestimmen
Schätzungen nach werden ca. 50% der gesamten Ressourcen der Kompilierung für die lexikalische Analyse verwendet
z.B. abhängig von:Einsatz von Leerzeichen
Verwendung von Schlüsselwörtern
Länge der Eingabe
Lookahead-Regeln
49
Optimierungsmöglichkeiten
Direkter Aufbau eines EA, ohne den Umweg über einen NEA
Kostenreduzierung
Ggfs. weniger Zustände
Minimierung der Anzahl der ZuständeEffiziente Mustererkennung durch Zusammenfassung der Zustände
Laufzeit O(n log n), wobei n = Anzahl der Zustände
Kompakterer Aufbau der Übergangstabellen