5490ce2bf23093de242ccc160dbfd3b639d.pptx

Saturday 21 December 2024 1
MODULE 2
LEXICAL ANALYSIS
VENKATESH BHAT
SENIOR ASSOCIATE PROFESSOR
DEPARTMENT OF CSE
AIET, MOODBIDRI

MODULE 2 SYLLABUS
•Regular Expressions and Languages: Regular Expressions,
Finite Automata and Regular Expressions, Proving Languages
Not to Be Regular
•Lexical Analysis Phase of compiler Design: Role of Lexical
Analyzer, Input Buffering, Specification of Token, Recognition
of Token.
•Textbook 1: Chapter3 – 3.1, 3.2, Chapter4- 4.1
•Textbook 2: Chapter3- 3.1 to 3.4

3.1 Role of Lexical Analyzer
Interaction between the lexical analyzer and the parser

3.1.1 Lexical Analysis versus Parsing
Why analysis portion is divided into lexical analysis and syntax analysis (parsing) ?
1. Simplicity of Design is the most important consideration.
2. Compiler Efficiency is improved
3. Compiler Portability is enhanced

Simplicity of Design is the most important consideration
■The separation of Lexical and Syntactic analysis often allows
us to simplify at least one of these tasks.
■For example, A parser that had to deal with comments and
white spaces as syntactic units would be considerably more
complex that one can assume white space and comments
have already been removed by the Lexical Analyzer.

Compiler Efficiency is improved
A separate Lexical Analyzer allows us to apply specialized techniques
that serve only the Lexical task, not the job of Parsing.
Compiler Portability is enhanced :
Input device specific peculiarities can be restricted to the Lexical Analyzer.

Tokens, Patterns and Lexems
■Token : A token is a pair consisting of a token name and an optional
attribute value.
■The token name is a abstract symbol representing a kind of Lexical
Unit.
■Example : A particular keyword or a sequence of input characters
denoting a identifier.
■The token name are the input symbol that the parser process.
■Token is referred by token name

Tokens, Patterns and Lexems
■Patterns : It is a description of the form that the Lexemes of a
token may take.
■Eg: In case of a keyword as a token, the pattern is just the sequence
of characters that form the keyword.
■Lexeme: It is a sequence of characters in the source program that
matches the pattern for a token and is identified by the lexical
analyzer as an instance of that token.

Example
Consider an Example of C Statement:
printf (“Total = %dn”,score);
Here,
printf and score are Lexemes matching the pattern for token identifier
“Total = %dn” is a Lexeme matching Literals.

Sample Lexemes Description (Pattern) Token
If
else
<=, !=
pi, score
3.1415
“Core dumped”
characters i, f
characters e, 1, s, e
< or > or <= or >= or == or ! =
letter followed by letters and digits
any numeric constant
anything but , surrounded by "'s
if
else
comparison operator
id
constant
Literals

Attributes for tokens
■When more than one lexeme can match a pattern, the lexical
analyzer must provide the subsequent compiler phases additional
information about the particular lexeme that matched. For example,
the pattern for token number matches both 0 and 1
■Lexical analyzer returns to the parser not only a token name, but an
attribute value that describes the lexeme represented by the token.
■Token name influences the parsing decisions, while the attribute
value influences translation of tokens after parse.
■Thus, appropriate Attribute value for an identifier is a pointer to the
symbol-table entry for that identifier.

Example
The token names and associated attribute values for the Fortran
statement E = M * C ** 2 are written below as a sequence of pairs.
<id, pointer to the symbol table entry for E>
<assign_op>
<id, pointer to the symbol table entry for M>
<mult_op>
<id, pointer to the symbol table entry for C>
<exp_op>
<number, integer value 2>

Lexical errors
❑It is hard for a lexical analyzer to tell, without the help of
other components, that there is a source-code error.
❑For instance,
fi ( a= = f(x))
❑A lexical analyzer cannot tell whether fi is a misspelling of
the keyword if or an undeclared function identifier.

Possible error recovery actions
Delete successive characters from the remaining input, until the
lexical analyzer can find a well-formed token at the beginning of
what input is left.
Delete one character from the remaining input
Insert a missing character into the remaining input
Replace a character by another character
Transpose two adjacent character

Input buffering
❑Let us examine some ways that are simple but important task of reading
the source program can be speeded.
❑We often have to look one or more characters beyond the next lexeme
before we can be sure we have the right lexeme.
❑For instance, we cannot be sure we've seen the end of an identifier until
we see a character that is not a letter or digit, and therefore is not part of
the lexeme for id.
❑In C, single-character operators like -, =, or < could also be the beginning
of a two-character operator like ->, ==, or <=. Thus, we shall introduce a
two-buffer scheme that handles large lookaheads safely.

1) Buffer Pairs
❑Because of the amount of time taken to process characters during the
compilation of the source program, Specialized buffering techniques have been
developed to reduce the amount of overhead required to process a single input
character.
❑This scheme involves two buffers that are alternately reloaded.
❑Each buffer is of same size N, and N is usually the size of a disk block. Ex:4096
bytes
❑One system read command is used to read N characters instead of using one
system call per character.
❑If fewer than N characters remain in the input file , then special character,
represented by eof, marks the end of source file.

Buffer Pairs (contd..)
■ Two pointers to the input are maintained
❑Pointer lexemeBegin, marks the beginning of the current
lexeme, whose extent we are attempting to determine.
❑Pointer forward scans ahead until a pattern match is found.
❑Once the next lexeme is determined, forward is set to the
character at its right end.
❑After the lexeme is recorded as an attribute value of a token
returned to the parser, lexemeBegin is set to the character
immediately after the lexeme just found.

Using a pair of input buffers
E = M * C * * 2 eof
Lexeme Begin
Forward

2. Sentinels
■ Advancing the forward requires that we first test whether we have
reached the end of the buffers.
■ If so we must reload the other buffer from the input and move forward to
the beginning of the newly loaded buffer.
■ Thus for each character read, we make two tests:
❑ One for the end of the buffer
❑ Other to determine what character is read
■ We can combine the buffer end test with the test for the current character
if we extend each buffer to hold a sentinel character at the end.

Sentinels
■Definition:
The sentinel is a special character that cannot be part of the source
program, and the natural choice is the character eof
■ Note that eof retains its use as a marker for the end of the of the
entire input.
■ Any eof that appears other than at the end of the buffer means
that the input is at an end.

Sentinels at the end of each buffer

Lookahead code with Sentinels
Switch(*forward++)
{
case eof:
if (forward is at end of first buffer)
{ reload second buffer;
forward = beginning of second buffer;
}
else if (forward is at end of second buffer)
{ reload first buffer;
forward = beginning of first buffer;
}
else /* eof within a buffer marks the end of input terminate lexical analysis*/
break;
case for the other characters
}

3.3 Specification of tokens
■Regular expressions are the notations for specifying
lexeme patterns.

3.3.1 Strings and languages
■ Alphabet: finite non empty set of symbols
❑ Eg: binary alphabet
■ Strings: Finite sequence of symbols over an alphabet ∑.
❑ Finite sequence of symbols on an alphabet
❑ Sentence and word are also used in terms of string
❑ ε is the empty string
❑ |s| is the length of string s.
■ Languages: A language is a set of all strings over alphabet ∑

3.3.2 Operations on Languages
Operation Definition and notation
Union of L and M L U M={s | s is in L or s is in M}
Concatenation of L and M LM={st | s is in L and t is in M}
Kleene Closure of L L*=
Positive Closure of L L+
=

Example
■L = {a,b,c,d} L2 = {1,2}
■L1L2 = {a1,a2,b1,b2,c1,c2,d1,d2}
■L1 L
∪ 2 = {a,b,c,d,1,2}
■L1
3
= all strings with length three (using a, b, c, d}
■L1
*
= all strings using letters a, b, c, d and empty string
■L1
+
= doesn’t include the empty string

3.3.3 Regular Expressions (Rules)
Regular expressions over alphabet Σ
Reg. Expr Language it denotes
ε {ε}
a Σ
∈ {a}
Ø {Ø}
Induction
If r and s are the regular expression denoting languages L(r ) and L(s) then
1) (r) | (s) is a regular expression denoting a language L(r) L(s)
∪
2) (r) (s) is a regular expression denoting a language L(r) L(s)
3) (r)*
is a regular expression denoting a language (L(r))*
4) (r) is a regular expression denoting a language L(r)

Precedence rules
❑Unary operator * highest
❑concatenation next highest
❑ Union | lowest
All are left associative

Example
Let Σ = {0,1}
❑Regular expression 0|1 denotes the language {0,1}
❑(0|1)(0|1) => {00,01,10,11}
❑0*
=> {ε,0,00,000,0000,....}
❑(0|1)*
=> all strings with 0 and 1, including the empty string

Algebraic Laws for regular expressions
LAW DESCRIPTION
r | s = s | r | is commutative
r | (s | t) = (r | s) | t | is associative
r (st) =(rs) t Concatenation is associative
r (s | t) = rs | rt; (s|t) r =sr | tr Concatenation distributes over |
Ɛ r = r Ɛ = r Ɛ is the identity for Concatenation
r* =( r | Ɛ ) * Ɛ is guaranteed in closure
r**= r* * is idempotent

3.3.4 Regular definition
■To write regular expression for some languages can be difficult, because their regular
expressions can be quite complex. In those cases, we may use regular definitions.
■We can give names to regular expressions, and we can use these names as symbols
to define other regular expressions.
■Definition:
If ∑ is an alphabet of basic symbols, then A regular definition is a sequence of the
definitions of the form:
d1 → r1
d2 → r2
. . . .
dn → rn
Where:
■Each di is a new symbol, not in ∑ and not the same as any
other of the d’s
■Each ri is a Regular Expression over the alphabet
∑ U {d1, d2, d3,………di-1}

Ex 1: Regular definition for Identifier in C
■ letter → A | B | ... | Z | a | b | ... | z| _
digit → 0 | 1 | ... | 9
id → letter _ (letter_ | digit ) *
❑If we try to write the regular expression representing identifiers
without using regular definitions, that regular expression will be
complex.
(A|...|Z|a|...|z|_ ) ( (A|...|Z|a|...|z|_ ) | (0|...|9) ) *

Extensions of Regular expressions
 One or More instances
 Zero of One Instance
 One or More instances
 Zero of One Instance

One or More instances
■The Unary Postfix operator ‘+’ represents the positive
closure of a regular expression, that is if r is a regular
expression, then (r)+
denotes the Language (L(r))+
.
■The unary operator ‘+’ has the same precedence and
associativity as the operator ‘*’.

Zero of One Instance
■The unary postfix operator ‘?’ means Zero or One
occurrence,
■that is, r? is equivalent to r | ε and L(r?) = L(r) υ { ε }
■The ? operator has the same precedence and associativity
as * and +.

Character Classes
■A regular expressions a1 | a2 | a3 | ………. an Where ai’s are each
symbols of the alphabet, can be replaced by short hands
[a1 a2…………… an]
Eg: [abc] is shorthand for a | b | c
[a-z] is shorthand for a | b | c | ……………. | z
Activity : Using the short hands rewrite the regular definition given
for identifiers and unsigned numbers

Write a Regular definition using extension
to recognize Identifier
letter [ A - Z a-z _ ]
digit  [ 0 - 9 ]
id  letter (letter | digit)*

Write a Regular definition using extension
to recognize Unsigned numbers
digit  [0-9]
digits  digit +
number  digits (.digits)? ( E [ + - ]? digits )?

3.4 Recognition of tokens
■Till now we have seen how to express patterns using
regular expression, now will see how the patterns for all
needed tokens are taken to build a code that examines the
input and finds the lexeme matching one or more patterns.

Consider a Grammar for branching statements
stmt  if expr then stmt
| if expr then stmt else stmt
| ε
expr  term relop term
| term
term  id | number
Here the terminal symbols if, then, else, relop, id and number are
names of tokens

Patterns for these tokens are given using regular
definitions as follows:
digit  [0-9]
digits  digit +
number  digits ( .digits )? ( E [ + - ]? digits)?
letter  letter (letter | digit )*
if  if
else  else
then  then
relop  < | > | <= | = | < >

In addition we assign the lexical analyzer the job
of stripping out whitespace by recognizing the
“token” ws defined by:
ws  (blank | tab | newline)+
■ws token is different from other tokens.
■This token is not returned to the parser instead it will restart
lexical analysis from the character following the whitespace.

Table shows for each lexeme what is the token name and the attribute value.
Lexemes Taken name attribute value
Any ws - -
if if -
then then -
else else -
Any id id pointer to tables entry
Any number number pointer to tables entry
< relop LT
< = relop LE
> relop GT
> = relop GE
= relop EQ
< > relop NE

3.4.1 Transition diagrams
■An intermediate step in the construction of lexical analyzer is conversion
of patterns into stylized flowcharts called “transition diagrams”
■Transition diagrams have a collection of node or circles called states.
■Each state represents a condition that could occur during the process of
scanning the input, looking for a lexeme that matches one of several
patterns.

3.4.1 Transition diagrams
■When we think about a state all we need to know is what
characters are seen between lexemeBegin and forward pointer.
■Edges are directed from one state of the transition diagrams to
other. Each edge is labeled by a symbol or set of symbols.
■All the transition diagrams are assumed to be deterministic

Conventions about transition diagrams
Certain states are said to be accepting state or final state - indicate that
a lexeme has been found.
Action to be taken ---return a token & attribute value to the
parser and attach the action to the accepting state.
If it is necessary to retract the forward pointer one position, we place a
* at the final (accepting) state. In our example, it is never necessary to
retract forward by more than one position, but if it were, we could
attach any number of * to the accepting state.
One state is start state or initial state indicated by an edge labeled “start” .

Transition diagram that recognizes the
lexemes matching the token relop on PASCAL

3.4.2 Transition diagram for Recognition of identifiers

How to handle reserved words that
look like identifier?
There are 2 ways
1) Install the reserved words in the symbol table initially.
2) Create separate transition diagrams for each keyword

Install the reserved words in the symbol table initially
■A field of the symbol-table entry indicates that these strings are never
ordinary identifiers, and tells which token they represent.
■When we find an identifier, a call to installlD places it in the symbol
table if it is not already there and returns a pointer to the symbol-table
entry for the lexeme found.
■Any identifier not in the symbol table during lexical analysis cannot be
a reserved word, so its token is id.
■The function getToken examines the symbol table entry for the lexeme
found, and returns whatever token name the symbol table says this
lexeme represents — either id or one of the keyword tokens that was
initially installed in the table.

Create separate transition diagrams for each keyword
Such a transition diagram consists of states representing the situation
after each successive letter of the keyword is seen.
■This is followed by a test for a "nonletter-or-digit," any character that
cannot be the continuation of an identifier.
■It is necessary to check that the identifier has ended, or else we
would return token for keyword then in situations where the correct
token was id, with a lexeme like thenextvalue that has then as a proper
prefix.
■ If we adopt this approach, then we must prioritize the tokens so
that the reserved-word tokens are recognized in preference to id.

Transition diagram for keyword then
Second approach is not usually used. That’s why the states in
the transition diagram are unnumbered.

Transition diagram for unsigned numbers

Transition diagram for whitespace

3.4.4 Architecture of a transition diagram based lexical Analyzer
■There are several ways that a collection of transition diagrams can
be used to build a lexical analyzer.
■Each state is represented by a piece of code.
■Variable state holds the number of the current state for a
transition diagram.
■A switch based on the value of state takes us to code for each of
the possible states, where we find the action of that state.

Implementation of relop transition diagram
TOKEN getRelop( )
{
TOKEN retToken = new(RELOP);
while(1)
{ /* repeat character processing until a return or failure occurs */
switch(state)
{
case 0: c = nextchar( );
if ( c = = ‘<’ ) state =1;
else if ( c = = ‘=’ ) state =5;
else if ( c = = ‘>’ ) state =6;
else fail( ); /* lexeme is not a relop */
break;
case 1: . . . .
. . . . .
. . . . .
case 8: retract( );
retToken.attribute =GT;
return(retToken);
}
}
}

■getRelop( ) is a C+ + function whose job is to simulate the
transition diagram for relop and return an object of type
TOKEN. (in this case token is relop)
■getRelop( ) first creates a new object retToken and initializes
its first component to RELOP, the symbolic code for token relop.
■A function nextChar() obtains the next character from the input
and assigns it to local variable c.
■We then check c for the three characters we expect to find, For
example, if the next input character is =, we go to state 5.

■If the next input character is not one that can begin a comparison operator,
then a function fail () is called.
■fail() should reset the forward pointer to lexemeBegin, in order to allow
another transition diagram to be applied to the true beginning of the
unprocessed input.
■It might then change the value of state to be the start state for another
transition diagram, which will search for another token.
■Since state 8 bears a *, we must retract the input pointer one position (i.e.,
put c back on the input stream).
■ That task is accomplished by the function retract () and we set the second
component of the returned object, which we suppose is named attribute, GT

END OF
MODULE 2 Part 2

END OF MODULE 2

5490ce2bf23093de242ccc160dbfd3b639d.pptx

More Related Content

Similar to 5490ce2bf23093de242ccc160dbfd3b639d.pptx (20)

Recently uploaded (20)

5490ce2bf23093de242ccc160dbfd3b639d.pptx