Compiler1 Chapter V: Compiler Overview: r To study the design and operation of compiler for high-level programming languages. r Contents m Basic compiler (one-pass compiler) functions m Machine-dependent extension: (object-code generation & code optimization) m Compiler design alternative: multi-pass compiler, interpreters, p-code compilers & compiler-compilers.

Compiler2 r Example Basic compiler functions

Compiler3 Basic compiler functions (cont.) r Source program r Regard each statement as a sequence of token. m The task of scanning the source statement, recognizing and classifying the various tokens, is known as lexical analysis. (scanner) r Recognized all tokens as some language construct by the grammar. r This process is called syntactic analysis or parsing. (parser) r Generation of object code.

Compiler4 Compilation process r Scanning ( lexical analysis ) r Parsing ( syntactic analysis) r Code generation r Ps. It can achieve in a single pass !

Compiler5 Grammars r A grammar for a programming language is a formal description of the syntax, of programs and individual statements written in the language. r The difference between syntax and semantics, m E.g., I := J + K X := Y + I where X,Y : Real I,J,K : Integer They are identical syntax. However, the semantic are quite different.

Compiler6 Grammars (cont.) r BNF (Backus-Naur Form) m A kind of syntax description. m Simple. m Widely used. m It provide capabilities that are sufficient for most purposes. r BNF consists of a set of rules, each of which defines the syntax of some construct in the programming language. m E.g., ::= READ ( )

Compiler7 Grammars (cont.) m ::= READ ( ) m ::= id |, id m Character strings enclosed between are called nonterminal symbol. m Character strings not enclosed between are called terminal symbol (I.e, tokens). m E.g., READ(value, sum, x, y)

Compiler8 Simplified Pascal grammar

Compiler9 Simplified Pascal grammar (cont.)

Compiler10 Simplified Pascal grammar (cont.) r To display the analysis of a source statement in terms of a grammar a a tree (parse tree or syntax tree).

Compiler11 The parse tree for VARIANCE := SUMSQ DIV 100 – MEAN * MEAN

Compiler12 Grammars (cont.) r Draw parse tree for m ALPHA – BETA * GAMMA r If there is more than one possible parse tree for a given statement, the grammar is said to be ambiguous. r The ambiguous grammar would leave doubt about what object code should be generated.

Compiler13

Compiler14

Compiler15 Lexical analysis (scanning) r Scanning the program to be compiled and recognizing the tokens that make up the source statements. r Scanner are usually designed to recognize keywords, operators, and identifiers, integer, floating-point numbers, character strings, …,etc. r The identifier might be defined by the rules: m ::= | | m ::= A | B | C | D | … | Z m ::= 0 | 1 | 2 | 3 | … | 9

Compiler16 Token coding scheme

Compiler17 Lexical scan

Compiler18 The lexical scanning r It must deal with the following cases: r For example, m DO 10 I = 1, 100 m DO 10 I =1 m (FORTRAN ignores blank in the statement) r IF (THEN.EQ. ELSE) THEN IF = THEN ELSE THEN = IF ENDIF r A number of tools have been developed for automatically constructing lexical scanners from specifications stated in a special-purpose language.

Compiler19 Modeling Scanners as Finite Automata r The tokens of most programming languages can be recognized by a finite automation. r Starting state vs. final state. r If the automation stops in a final state, we say that it recognizes (or accept) the string being scanned, otherwise, it fails to recognize the string.

Compiler20 Modeling Scanners as Finite Automata (cont.)

Compiler21 Modeling Scanners as Finite Automata (cont.)

Compiler22 Modeling Scanners as Finite Automata (cont.)

Compiler23 Modeling Scanners as Finite Automata (cont.)

Compiler24 The implementation of finite automata r Using algorithm code (for Fig. 5.8 (b))

Compiler25 r Using tabular representation The implementation of finite automata (cont.)