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