CSE 401/M501 Compilers

Similar documents
Languages, Automata, Regular Expressions & Scanners. Winter /8/ Hal Perkins & UW CSE B-1

CSEP 501 Compilers. Languages, Automata, Regular Expressions & Scanners Hal Perkins Winter /8/ Hal Perkins & UW CSE B-1

CSE 413 Programming Languages & Implementation. Hal Perkins Autumn 2012 Grammars, Scanners & Regular Expressions

CSE 413 Programming Languages & Implementation. Hal Perkins Winter 2019 Grammars, Scanners & Regular Expressions

Regular Expressions. Agenda for Today. Grammar for a Tiny Language. Programming Language Specifications

CSE 401 Compilers. Languages, Automata, Regular Expressions & Scanners Hal Perkins Winter UW CSE 401 Winter 2015 B-1

Lexical Analysis. Lexical analysis is the first phase of compilation: The file is converted from ASCII to tokens. It must be fast!

Lexical Analysis. Lecture 2-4

Lexical Analysis. Chapter 2

Lexical Analysis. Lecture 3-4

Introduction to Lexical Analysis

CSE P 501 Compilers. Parsing & Context-Free Grammars Hal Perkins Spring UW CSE P 501 Spring 2018 C-1

Implementation of Lexical Analysis

Formal Languages and Grammars. Chapter 2: Sections 2.1 and 2.2

Part 5 Program Analysis Principles and Techniques

Implementation of Lexical Analysis

CSc 453 Lexical Analysis (Scanning)

Figure 2.1: Role of Lexical Analyzer

Lexical Analysis. Chapter 1, Section Chapter 3, Section 3.1, 3.3, 3.4, 3.5 JFlex Manual

Interpreter. Scanner. Parser. Tree Walker. read. request token. send token. send AST I/O. Console

CS Lecture 2. The Front End. Lecture 2 Lexical Analysis

Administrivia. Lexical Analysis. Lecture 2-4. Outline. The Structure of a Compiler. Informal sketch of lexical analysis. Issues in lexical analysis

CSE 401 Midterm Exam Sample Solution 2/11/15

CSCI312 Principles of Programming Languages!

CSE P 501 Compilers. Parsing & Context-Free Grammars Hal Perkins Winter /15/ Hal Perkins & UW CSE C-1

Compiler course. Chapter 3 Lexical Analysis

Compiler phases. Non-tokens

Syntax. Syntax. We will study three levels of syntax Lexical Defines the rules for tokens: literals, identifiers, etc.

CSE 3302 Programming Languages Lecture 2: Syntax

Lexical Analysis. Introduction

Concepts. Lexical scanning Regular expressions DFAs and FSAs Lex. Lexical analysis in perspective

MIT Specifying Languages with Regular Expressions and Context-Free Grammars

Formal Languages and Compilers Lecture VI: Lexical Analysis

Chapter 3 Lexical Analysis

CS415 Compilers. Lexical Analysis

CSE302: Compiler Design

Lexical Analysis. Dragon Book Chapter 3 Formal Languages Regular Expressions Finite Automata Theory Lexical Analysis using Automata

Chapter 4. Lexical analysis. Concepts. Lexical scanning Regular expressions DFAs and FSAs Lex. Lexical analysis in perspective

CS 314 Principles of Programming Languages. Lecture 3

CSCE 314 Programming Languages

MIT Specifying Languages with Regular Expressions and Context-Free Grammars. Martin Rinard Massachusetts Institute of Technology

COMP-421 Compiler Design. Presented by Dr Ioanna Dionysiou

COP4020 Programming Languages. Syntax Prof. Robert van Engelen

Lexical Analyzer Scanner

CMSC 350: COMPILER DESIGN

Lecture 4: Syntax Specification

programming languages need to be precise a regular expression is one of the following: tokens are the building blocks of programs

Lexical Analysis. COMP 524, Spring 2014 Bryan Ward

Lexical Analyzer Scanner

Languages and Compilers

COP4020 Programming Languages. Syntax Prof. Robert van Engelen

Theory and Compiling COMP360

CS321 Languages and Compiler Design I. Winter 2012 Lecture 4

Programming Languages (CS 550) Lecture 4 Summary Scanner and Parser Generators. Jeremy R. Johnson

Implementation of Lexical Analysis

CS412/413. Introduction to Compilers Tim Teitelbaum. Lecture 2: Lexical Analysis 23 Jan 08

Chapter 2 :: Programming Language Syntax

CSE 401 Midterm Exam 11/5/10

Structure of Programming Languages Lecture 3

About the Tutorial. Audience. Prerequisites. Copyright & Disclaimer. Compiler Design

CPS 506 Comparative Programming Languages. Syntax Specification

Syntactic Analysis. CS345H: Programming Languages. Lecture 3: Lexical Analysis. Outline. Lexical Analysis. What is a Token? Tokens

CS 403: Scanning and Parsing

Compiler Construction D7011E

Implementation of Lexical Analysis

THE COMPILATION PROCESS EXAMPLE OF TOKENS AND ATTRIBUTES

CS 314 Principles of Programming Languages

Homework & Announcements

CSc 453 Compilers and Systems Software

Lexical and Syntax Analysis

Lexical Analysis. Implementation: Finite Automata

Lexical Analysis. Note by Baris Aktemur: Our slides are adapted from Cooper and Torczon s slides that they prepared for COMP 412 at Rice.

The Front End. The purpose of the front end is to deal with the input language. Perform a membership test: code source language?

Parsing and Pattern Recognition

Lexical Scanning COMP360

Chapter 3: Lexing and Parsing

CSE Lecture 4: Scanning and parsing 28 Jan Nate Nystrom University of Texas at Arlington

Lexical Analysis 1 / 52

CSE 105 THEORY OF COMPUTATION

Week 2: Syntax Specification, Grammars

CSE 582 Autumn 2002 Exam Sample Solution

CSE P 501 Compilers. Parsing & Context-Free Grammars Hal Perkins Winter UW CSE P 501 Winter 2016 C-1

Chapter 2 - Programming Language Syntax. September 20, 2017

COP 3402 Systems Software Syntax Analysis (Parser)

CSC 467 Lecture 3: Regular Expressions

CSE P 501 Compilers. LR Parsing Hal Perkins Spring UW CSE P 501 Spring 2018 D-1

CS 4240: Compilers and Interpreters Project Phase 1: Scanner and Parser Due Date: October 4 th 2015 (11:59 pm) (via T-square)

Last lecture CMSC330. This lecture. Finite Automata: States. Finite Automata. Implementing Regular Expressions. Languages. Regular expressions

Lexical Analysis - An Introduction. Lecture 4 Spring 2005 Department of Computer Science University of Alabama Joel Jones

Lexical Analysis. Lecture 3. January 10, 2018

10/4/18. Lexical and Syntactic Analysis. Lexical and Syntax Analysis. Tokenizing Source. Scanner. Reasons to Separate Lexical and Syntactic Analysis

Concepts Introduced in Chapter 3. Lexical Analysis. Lexical Analysis Terms. Attributes for Tokens

Building lexical and syntactic analyzers. Chapter 3. Syntactic sugar causes cancer of the semicolon. A. Perlis. Chomsky Hierarchy

Writing a Lexical Analyzer in Haskell (part II)

Introduction to Lexical Analysis

Compiler Construction

Announcements! P1 part 1 due next Tuesday P1 part 2 due next Friday

Theoretical Part. Chapter one:- - What are the Phases of compiler? Answer:

Administrativia. Extra credit for bugs in project assignments. Building a Scanner. CS164, Fall Recall: The Structure of a Compiler

Compiler Design. 2. Regular Expressions & Finite State Automata (FSA) Kanat Bolazar January 21, 2010

Transcription:

CSE 401/M501 Compilers Languages, Automata, Regular Expressions & Scanners Hal Perkins Spring 2018 UW CSE 401/M501 Spring 2018 B-1

Administrivia No sections this week Read: textbook ch. 1 and sec. 2.1-2.4 First homework: out later today or tomorrow, due next Thursday. Written problems on this weeks material. CSE M 501 exists! Will need to update infrastructure now that we re two courses so it still feels like just one If you haven t already, pick a project partner We ll post a form for ONE of you to send in partner info (+ 1 point for both of you if done right) UW CSE 401/M501 Spring 2018 B-2

Agenda Quick review of basic concepts of formal grammars Regular expressions Lexical specification of programming languages Using finite automata to recognize regular expressions Scanners and Tokens General ideas in lecture, then examples, details, and compiler applications in sections UW CSE 401/M501 Spring 2018 B-3

Programming Language Specs Since the 1960s, the syntax of every significant programming language has been specified by a formal grammar First done in 1959 with BNF (Backus-Naur Form), used to specify ALGOL 60 syntax Borrowed from the linguistics community (Chomsky) UW CSE 401/M501 Spring 2018 B-4

Formal Languages & Automata Theory (a review in one slide) Alphabet: a finite set of symbols and characters String: a finite, possibly empty sequence of symbols from an alphabet Language: a set of strings (possibly empty or infinite) Finite specifications of (possibly infinite) languages Automaton a recognizer; a machine that accepts all strings in a language (and rejects all other strings) Grammar a generator; a system for producing all strings in the language (and no other strings) A particular language may be specified by many different grammars and automata A grammar or automaton specifies only one language UW CSE 401/M501 Spring 2018 B-5

Language (Chomsky) hierarchy: quick reminder Regular (Type-3) languages are specified by regular expressions/grammars and finite automata (FSAs) Specs and implementation of scanners Context-free (Type-2) languages are specified by context-free grammars and pushdown automata (PDAs) Specs and implementation of parsers Context-sensitive (Type-1) languages aren t too important (at least for us) Recursively-enumerable (Type-0) languages are specified by general grammars and Turing machines Turing CSL CFL Regular UW CSE 401/M501 Spring 2018 6

Example: Grammar for a Tiny Language program ::= statement program statement statement ::= assignstmt ifstmt assignstmt ::= id = expr ; ifstmt ::= if ( expr ) statement expr ::= id int expr + expr id ::= a b c i j k n x y z int ::= 0 1 2 3 4 5 6 7 8 9 UW CSE 401/M501 Spring 2018 B-7

Exercise: Derive a simple program program ::= statement program statement statement ::= assignstmt ifstmt assignstmt ::= id = expr ; ifstmt ::= if ( expr ) statement expr ::= id int expr + expr id ::= a b c i j k n x y z int ::= 0 1 2 3 4 5 6 7 8 9 a = 1 ; if ( a + 1 ) b = 2 ; UW CSE 401/M501 Spring 2018 B-8

Productions The rules of a grammar are called productions Rules contain: Nonterminal symbols: grammar variables (program, statement, id, etc.) Terminal symbols: concrete syntax that appears in programs (a, b, c, 0, 1, if, =, (, ), Meaning of: nonterminal ::= <sequence of terminals and nonterminals> In a derivation, an instance of nonterminal can be replaced by the sequence of terminals and nonterminals on the right of the production Often there are several productions for a nonterminal can choose any in different parts of derivation UW CSE 401/M501 Spring 2018 B-9

Alternative Notations There are several notations for productions in common use; all mean the same thing ifstmt ::= if ( expr ) statement ifstmt if ( expr ) statement <ifstmt> ::= if ( <expr> ) <statement> UW CSE 401/M501 Spring 2018 B-10

Parsing Parsing: reconstruct the derivation (syntactic structure) of a program In principle, a single recognizer could work directly from a concrete, character-bycharacter grammar In practice this is never done UW CSE 401/M501 Spring 2018 B-11

Parsing & Scanning In real compilers the recognizer is split into two phases Scanner: translate input characters to tokens Also, report lexical errors like illegal characters and illegal symbols Parser: read token stream and reconstruct the derivation source Scanner tokens Parser UW CSE 401/M501 Spring 2018 B-12

Why Separate the Scanner and Parser? Simplicity & Separation of Concerns Scanner hides details from parser (comments, whitespace, input files, etc.) Parser is easier to build; has simpler input stream (tokens) and simpler interface for input Efficiency Scanner recognizes regular expressions proper subset of context free grammars (But still often consumes a surprising amount of the compiler s total execution time) UW CSE 401/M501 Spring 2018 B-13

But Not always possible to separate cleanly Example: C/C++/Java type vs identifier Parser would like to know which names are types and which are identifiers, but Scanner doesn t know how things are declared So we hack around it somehow Either use simpler grammar and disambiguate later, or communicate between scanner & parser Engineering issue: try to keep interfaces as simple & clean as possible UW CSE 401/M501 Spring 2018 B-14

Typical Tokens in Programming Languages Operators & Punctuation + - * / ( ) { } [ ] ; : :: < <= == =!=! Each of these is a distinct lexical class Keywords if while for goto return switch void Each of these is also a distinct lexical class (not a string) Identifiers A single ID lexical class, but parameterized by actual id Integer constants A single INT lexical class, but parameterized by int value Other constants, etc. UW CSE 401/M501 Spring 2018 B-15

Principle of Longest Match In most languages, the scanner should pick the longest possible string to make up the next token if there is a choice Example return maybe!= iffy; should be recognized as 5 tokens RETURN ID(maybe) NEQ ID(iffy) SCOLON i.e.,!= is one token, not two; iffy is an ID, not IF followed by ID(fy) UW CSE 401/M501 Spring 2018 B-16

Lexical Complications Most modern languages are free-form Layout doesn t matter Whitespace separates tokens Alternatives Fortran line oriented Haskell, Python indentation and layout can imply grouping And other confusions In C++ or Java, is >> a shift operator or the end of two nested templates or generic classes? UW CSE 401/M501 Spring 2018 B-17

Regular Expressions and FAs The lexical grammar (structure) of most programming languages can be specified with regular expressions (Sometimes a little cheating is needed) Tokens can be recognized by a deterministic finite automaton Can be either table-driven or built by hand based on lexical grammar UW CSE 401/M501 Spring 2018 B-18

Regular Expressions Defined over some alphabet Σ For programming languages, alphabet is usually ASCII or Unicode If re is a regular expression, L(re) is the language (set of strings) generated by re UW CSE 401/M501 Spring 2018 B-19

Fundamental REs re L(re ) Notes a { a } Singleton set, for each a in Σ ε { ε } Empty string { } Empty language UW CSE 401/M501 Spring 2018 B-20

Operations on REs re L(re ) Notes rs L(r)L(s) Concatenation r s L(r) L(s) Combination (union) r* L(r)* 0 or more occurrences (Kleene closure) Precedence: * (highest), concatenation, (lowest) Parentheses can be used to group REs as needed In real regular expression tools, need some way to escape literal * or characters vs. operators but don t worry, or use different fonts, for math. regexps. UW CSE 401/M501 Spring 2018 B-21

Examples re Meaning + single + character! single! character = single = character!= 2 character sequence "!=" xyzzy 5 character sequence xyzzy (1 0)* 0 or more binary digits (1 0)(1 0)* 1 or more binary digits 0 1(0 1)* sequence of binary digits with no leading 0 s, except for 0 itself UW CSE 401/M501 Spring 2018 B-22

Abbreviations The basic operations generate all possible regular expressions, but there are common abbreviations used for convenience. Some examples: Abbr. Meaning Notes r+ (rr*) 1 or more occurrences r? (r ε) 0 or 1 occurrence [a-z] (a b z) 1 character in given range [abxyz] (a b x y z) 1 of the given characters UW CSE 401/M501 Spring 2018 B-23

More Examples re Meaning [abc]+ [abc]* [0-9]+ [1-9][0-9]* [a-za-z][a-za-z0-9_]* UW CSE 401/M501 Spring 2018 B-24

Abbreviations Many systems allow abbreviations to make writing and reading definitions or specifications easier name ::= re Restriction: abbreviations may not be circular (recursive) either directly or indirectly (else would be non-regular) UW CSE 401/M501 Spring 2018 B-25

Example Possible syntax for numeric constants digit ::= [0-9] digits ::= digit+ number ::= digits (. digits )? ( [ee] (+ -)? digits )? How would you describe this set in English? What are some examples of legal constants (strings) generated by number? What are the differences between these and numeric constants in YFPL? (Your Favorite Programming Language) UW CSE 401/M501 Spring 2018 B-26

Recognizing REs Finite automata can be used to recognize strings generated by regular expressions Can build by hand or automatically Reasonably straightforward, and can be done systematically Tools like Lex, Flex, JFlex et seq do this automatically, given a set of Res Same techniques used for grep, sed, other regular expression packages/tools UW CSE 401/M501 Spring 2018 B-27

Finite State Automaton A finite set of states One marked as initial state One or more marked as final states States sometimes labeled or numbered A set of transitions from state to state Each labeled with symbol from Σ, or ε Common to allow multiple labels (symbols) on one edge to simplify diagrams Operate by reading input symbols (usually characters) Transition can be taken if labeled with current symbol ε-transition can be taken at any time Accept when final state reached & no more input Slightly different in a scanner where the FSA is a subroutine that accepts the longest input string matching a token regular expression, starting at the current location in the input Reject if no transition possible, or no more input and not in final state (DFA) Some versions (including textbook) have an explicit error state and transitions to it on all no legal transition possible input. OK to omit that for CSE 401 UW CSE 401/M501 Spring 2018 B-28

Example: FSA for cat c a t UW CSE 401/M501 Spring 2018 B-29

DFA vs NFA Deterministic Finite Automata (DFA) No choice of which transition to take under any condition No ε transitions (arcs) Non-deterministic Finite Automata (NFA) Choice of transition in at least one case Accept if some way to reach a final state on given input Reject if no possible way to final state i.e., may need to guess right path or backtrack UW CSE 401/M501 Spring 2018 B-30

FAs in Scanners Want DFA for speed (no backtracking) But conversion from regular expressions to NFA is easy Fortunately, there is a well-defined procedure for converting a NFA to an equivalent DFA (subset construction) UW CSE 401/M501 Spring 2018 B-31

From RE to NFA: base cases a ε UW CSE 401/M501 Spring 2018 B-32

r s r ε s UW CSE 401/M501 Spring 2018 B-33

r s r ε ε ε s ε UW CSE 401/M501 Spring 2018 B-34

r * r ε ε ε UW CSE 401/M501 Spring 2018 B-35

Exercise Draw the NFA for: b(at ag) bug UW CSE 401/M501 Spring 2018 B-36

From NFA to DFA Subset construction Construct a DFA from the NFA, where each DFA state represents a set of NFA states Key idea State of the DFA after reading some input is the set of all NFA states that could have reached after reading the same input Algorithm: example of a fixed-point computation If NFA has n states, DFA has at most 2 n states => DFA is finite, can construct in finite # steps Resulting DFA may have more states than needed See books for construction and minimization details UW CSE 401/M501 Spring 2018 B-37

Exercise Build DFA for b(at ag) bug, given the NFA UW CSE 401/M501 Spring 2018 B-38

To Tokens A scanner is a DFA that finds the next token each time it is called Every final state of scanner DFA emits (returns) a token Tokens are the internal compiler names for the lexemes == becomes EQUAL ( becomes LPAREN while becomes WHILE xyzzy becomes ID(xyzzy) You choose the names Also, there may be additional data \r\n might count lines; token data structure might include source line numbers UW CSE 401/M501 Spring 2018 B-39

DFA => Code Option 1: Implement by hand using procedures one procedure for each token each procedure reads one character choices implemented using if and switch statements Pros straightforward to write fast Cons a lot of tedious work may have subtle differences from the language specification UW CSE 401/M501 Spring 2018 B-40

DFA => Code [continued] Option 1a: Like option 1, but structured as a single procedure with multiple return points choices implemented using if and switch statements Pros also straightforward to write faster Cons a lot of tedious work may have subtle differences from the language specification UW CSE 401/M501 Spring 2018 B-41

DFA => code [continued] Option 2: use tool to generate table driven scanner Rows: states of DFA Columns: input characters Entries: action Go to next state Accept token, go to start state Error Pros Convenient Exactly matches specification, if tool generated Cons Magic UW CSE 401/M501 Spring 2018 B-42

DFA => code [continued] Option 2a: use tool to generate scanner Transitions embedded in the code Choices use conditional statements, loops Pros Convenient Exactly matches specification, if tool generated Cons Magic Lots of code big but potentially quite fast Would never write something like this by hand, but can generate it easily enough UW CSE 401/M501 Spring 2018 B-43

Example: DFA for hand-written scanner Idea: show a hand-written DFA for some typical programming language constructs Then use to outline a hand-written scanner Setting: Scanner is called whenever the parser needs a new token Scanner knows (saves) current position in input From there, use a DFA to recognize the longest possible input sequence that makes up a token and return that token; save updated position for next time Disclaimer: Example for illustration only you ll use tools for the course project & we re abusing the DFA notation a little not all arrows in the diagram correspond to consuming an input character, but meaning should be pretty obvious UW CSE 401/M501 Spring 2018 B-44

Scanner DFA Example (1) 0 whitespace or comments end of input 1 Accept EOF ( 2 Accept LPAREN ) 3 Accept RPAREN ; 4 Accept SCOLON UW CSE 401/M501 Spring 2018 B-45

Scanner DFA Example (2)! 5 = 6 Accept NEQ [other ] 7 Accept NOT < 8 = 9 Accept LEQ [other ] 10 Accept LESS UW CSE 401/M501 Spring 2018 B-46

Scanner DFA Example (3) [0-9] 11 [0-9] [other ] 12 Accept INT UW CSE 401/M501 Spring 2018 B-47

Scanner DFA Example (4) [a-za-z] 13 [a-za-z0-9_] [other ] 14 Accept ID or keyword Strategies for handling identifiers vs keywords Hand-written scanner: look up identifier-like things in table of keywords to classify (good application of perfect hashing) Machine-generated scanner: generate DFA will appropriate transitions to recognize keywords Lots o states, but efficient (no extra lookup step) UW CSE 401/M501 Spring 2018 B-48

Implementing a Scanner by Hand Token Representation A token is a simple, tagged structure public class Token { public int kind; // token s lexical class public int intval; // integer value if class = INT public String id; // actual identifier if class = ID // useful extra information for debugging / diagnostics: public int line; public int column; // lexical classes (ancient java better to use enums) public static final int EOF = 0; // end of file token public static final int ID = 1; // identifier, not keyword public static final int INT = 2; // integer public static final int LPAREN = 4; public static final int SCOLN = 5; public static final int WHILE = 6; // etc. etc. etc. UW CSE 401/M501 Spring 2018 B-49

Simple Scanner Example // global state and methods static char nextch; // next unprocessed input character // advance to next input char void getch() { } // skip whitespace and comments void skipwhitespace() { } UW CSE 401/M501 Spring 2018 B-50

Scanner gettoken() method // return next input token public Token gettoken() { Token result; skipwhitespace(); if (no more input) { result = new Token(Token.EOF); return result; } switch(nextch) { case '(': result = new Token(Token.LPAREN); getch(); return result; case )': result = new Token(Token.RPAREN); getch(); return result; case ;': result = new Token(Token.SCOLON); getch(); return result; // etc. UW CSE 401/M501 Spring 2018 B-51

gettoken() (2) case '!': //! or!= getch(); if (nextch == '=') { result = new Token(Token.NEQ); getch(); return result; } else { result = new Token(Token.NOT); return result; } case '<': // < or <= getch(); if (nextch == '=') { result = new Token(Token.LEQ); getch(); return result; } else { result = new Token(Token.LESS); return result; } // etc. UW CSE 401/M501 Spring 2018 B-52

gettoken() (3) case '0': case '1': case '2': case '3': case '4': case '5': case '6': case '7': case '8': case '9': // integer constant String num = nextch; getch(); while (nextch is a digit) { num = num + nextch; getch(); } result = new Token(Token.INT, Integer(num).intValue()); return result; UW CSE 401/M501 Spring 2018 B-53

gettoken() (4) case 'a': case 'z': case 'A': case 'Z': // id or keyword string s = nextch; getch(); while (nextch is a letter, digit, or underscore) { s = s + nextch; getch(); } if (s is a keyword) { result = new Token(keywordTable.getKind(s)); } else { result = new Token(Token.ID, s); } return result; UW CSE 401/M501 Spring 2018 B-54

MiniJava Scanner Generation We ll use the jflex tool to automatically create a scanner from a specification file We ll use the CUP tool to automatically create a parser from a specification file Token class defs. shared by jflex and CUP. Lexical classes are listed in CUP s input file and it generates the token class definition. Details in next week s section UW CSE 401/M501 Spring 2018 B-55

Coming Attractions First homework: paper exercises on regular expressions, automata, etc. Then: first part of the compiler assignment the scanner Next topic: parsing Will do LR parsing first we need this for the project, then LL (recursive-descent) parsing, which you should also know. Good time to start reading ahead. UW CSE 401/M501 Spring 2018 B-56