LL(1) Parser

input buffer
– our string to be parsed. We will assume that its end is marked with a special symbol $.

output
– a production rule representing a step of the derivation sequence (left-most derivation) of the string in the input
buffer.

stack
– contains the grammar symbols
– at the bottom of the stack, there is a special end marker symbol $.
– initially the stack contains only the symbol $ and the starting symbol S. $S  initial stack
– when the stack is emptied (ie. only $ left in the stack), the parsing is completed.

parsing table
– a two-dimensional array M[A,a]
– each row is a non-terminal symbol
– each column is a terminal symbol or the special symbol $
– each entry holds a production rule.

CS416 Compiler Design 1

 LL(1) Parser – Parser Actions
• The symbol at the top of the stack (say X) and the current symbol in the input string (say
a) determine the parser action.
• There are four possible parser actions.
1. If X and a are $  parser halts (successful completion)
2. If X and a are the same terminal symbol (different from $)
 parser pops X from the stack, and moves the next symbol in the input buffer.
3. If X is a non-terminal
 parser looks at the parsing table entry M[X,a]. If M[X,a] holds a production rule
XY1Y2...Yk, it pops X from the stack and pushes Yk,Yk-1,...,Y1 into the stack. The parser
also outputs the production rule XY1Y2...Yk to represent a step of the derivation.
4. none of the above  error
– all empty entries in the parsing table are errors.
– If X is a terminal symbol different from a, this is also an error case.

CS416 Compiler Design 2

 LL(1) Parser – Example1
S  aBa a b $ LL(1) Parsing
B  bB |  S S  aBa Table
B B B  bB

stack input output

$S abba$ S  aBa
$aBa abba$
$aB bba$ B  bB
$aBb bba$
$aB ba$ B  bB
$aBb ba$
$aB a$ B
$a a$
$ $ accept, successful completion

CS416 Compiler Design 3

 LL(1) Parser – Example1 (cont.)

Outputs: S  aBa B  bB B  bB B

Derivation(left-most): SaBaabBaabbBaabba

S
parse tree
a B a

b B

b B


CS416 Compiler Design 4
 LL(1) Parser – Example2

E  TE’
E’  +TE’ | 
T  FT’
T’  *FT’ | 
F  (E) | id

id + * ( ) $
E E  TE’ E  TE’
E’ E’  +TE’ E’   E’  
T T  FT’ T  FT’
T’ T’   T’  *FT’ T’   T’  
F F  id F  (E)
CS416 Compiler Design 5
 LL(1) Parser – Example2
stack input output
$E id+id$ E  TE’
$E’T id+id$ T  FT’
$E’ T’F id+id$ F  id
$ E’ T’id id+id$
$ E ’ T’ +id$ T’  
$ E’ +id$ E’  +TE’
$ E’ T+ +id$
$ E’ T id$ T  FT’
$ E ’ T’ F id$ F  id
$ E’ T’id id$
$ E ’ T’ $ T’  
$ E’ $ E’  
$ $ accept

CS416 Compiler Design 6

 Constructing LL(1) Parsing Tables
• Two functions are used in the construction of LL(1) parsing tables:
– FIRST FOLLOW

• FIRST() is a set of the terminal symbols which occur as first symbols

in strings derived from  where  is any string of grammar symbols.
• if  derives to , then  is also in FIRST() .

• FOLLOW(A) is the set of the terminals which occur immediately after

(follow) the non-terminal A in the strings derived from the starting
symbol.
*
– a terminal a is in FOLLOW(A) if S  Aa
*
– $ is in FOLLOW(A) if S  A

CS416 Compiler Design 7

 Compute FIRST for Any String X
• If X is a terminal symbol  FIRST(X)={X}
• If X is a non-terminal symbol and X   is a production rule
  is in FIRST(X).
• If X is a non-terminal symbol and X  Y1Y2..Yn is a production rule
 if a terminal a in FIRST(Yi) and  is in all FIRST(Yj) for j=1,...,i-1
then a is in FIRST(X).
 if  is in all FIRST(Yj) for j=1,...,n
then  is in FIRST(X).
• If X is   FIRST(X)={}
• If X is Y1Y2..Yn  if a terminal a in FIRST(Yi) and  is
in all FIRST(Yj) for j=1,...,i-1 then a is in FIRST(X).
 if  is in all FIRST(Yj) for
j=1,...,n then  is in FIRST(X).

CS416 Compiler Design 8

 FIRST Example
E  TE’
E’  +TE’ | 
T  FT’
T’  *FT’ | 
F  (E) | id

FIRST(F) = {(,id} FIRST(TE’) = {(,id}

FIRST(T’) = {*, } FIRST(+TE’ ) = {+}
FIRST(T) = {(,id} FIRST() = {}
FIRST(E’) = {+, } FIRST(FT’) = {(,id}
FIRST(E) = {(,id} FIRST(*FT’) = {*}
FIRST() = {}
FIRST((E)) = {(}
FIRST(id) = {id}

CS416 Compiler Design 9

 Compute FOLLOW (for non-terminals)
• If S is the start symbol  $ is in FOLLOW(S)

• if A  B is a production rule

 everything in FIRST() is FOLLOW(B) except 

• If ( A  B is a production rule ) or
( A  B is a production rule and  is in FIRST() )
 everything in FOLLOW(A) is in FOLLOW(B).

We apply these rules until nothing more can be added to any follow set.

CS416 Compiler Design 10

 FOLLOW Example
E  TE’
E’  +TE’ | 
T  FT’
T’  *FT’ | 
F  (E) | id

FOLLOW(E) = { $, ) }
FOLLOW(E’) = { $, ) }
FOLLOW(T) = { +, ), $ }
FOLLOW(T’) = { +, ), $ }
FOLLOW(F) = {+, *, ), $ }

CS416 Compiler Design 11

 Constructing LL(1) Parsing Table -- Algorithm
• for each production rule A   of a grammar G
– for each terminal a in FIRST()
 add A   to M[A,a]
– If  in FIRST()
 for each terminal a in FOLLOW(A) add A   to M[A,a]
– If  in FIRST() and $ in FOLLOW(A)
 add A   to M[A,$]

• All other undefined entries of the parsing table are error entries.

CS416 Compiler Design 12

 Constructing LL(1) Parsing Table -- Example
E  TE’ FIRST(TE’)={(,id}  E  TE’ into M[E,(] and M[E,id]

E’  +TE’ FIRST(+TE’ )={+}  E’  +TE’ into M[E’,+]

E’   FIRST()={}  none
but since  in FIRST()
and FOLLOW(E’)={$,)}  E’   into M[E’,$] and M[E’,)]

T  FT’ FIRST(FT’)={(,id}  T  FT’ into M[T,(] and M[T,id]

T’  *FT’ FIRST(*FT’ )={*}  T’  *FT’ into M[T’,*]

T’   FIRST()={}  none
but since  in FIRST()
and FOLLOW(T’)={$,),+}  T’   into M[T’,$], M[T’,)] and M[T’,+]

F  (E) FIRST((E) )={(}  F  (E) into M[F,(]

F  id FIRST(id)={id}  F  id into M[F,id]

CS416 Compiler Design 13

 LL(1) Grammars
• A grammar whose parsing table has no multiply-defined entries is said
to be LL(1) grammar.

one input symbol used as a look-head symbol do determine parser action

LL(1) left most derivation

input scanned from left to right

• The parsing table of a grammar may contain more than one production
rule. In this case, we say that it is not a LL(1) grammar.

CS416 Compiler Design 14

 A Grammar which is not LL(1)
SiCtSE | a FOLLOW(S) = { $,e }
EeS |  FOLLOW(E) = { $,e }
Cb FOLLOW(C) = { t }

FIRST(iCtSE) = {i}
a b e i t $
FIRST(a) = {a}
S Sa S  iCtSE
FIRST(eS) = {e}
E EeS E
FIRST() = {}
E
FIRST(b) = {b}
C Cb

two production rules for M[E,e]

Problem  ambiguity
CS416 Compiler Design 15
 Bottom-Up Parsing
• A bottom-up parser creates the parse tree of the given input starting
from leaves towards the root.
• A bottom-up parser tries to find the right-most derivation of the given
input in the reverse order.
S  ...   (the right-most derivation of )
 (the bottom-up parser finds the right-most derivation in the reverse
order)
• Bottom-up parsing is also known as shift-reduce parsing because its
two main actions are shift and reduce.
– At each shift action, the current symbol in the input string is pushed to a stack.
– At each reduction step, the symbols at the top of the stack (this symbol sequence is the right
side of a production) will replaced by the non-terminal at the left side of that production.
– There are also two more actions: accept and error.

CS416 Compiler Design 16

 Shift-Reduce Parsing
• A shift-reduce parser tries to reduce the given input string into the starting symbol.

a string  the starting symbol

reduced to

• At each reduction step, a substring of the input matching to the right side of a
production rule is replaced by the non-terminal at the left side of that production rule.
• If the substring is chosen correctly, the right most derivation of that string is created in
the reverse order.

Rightmost Derivation: *S 
rm

Shift-Reduce Parser finds: rm rm   ...  S

CS416 Compiler Design 17

 A Grammar which is not LL(1) (cont.)
• What do we have to do it if the resulting parsing table contains multiply defined entries?
– If we didn’t eliminate left recursion, eliminate the left recursion in the
grammar.
– If the grammar is not left factored, we have to left factor the grammar.
– If its (new grammar’s) parsing table still contains multiply defined entries,
that grammar is ambiguous or it is inherently not a LL(1) grammar.
• A left recursive grammar cannot be a LL(1) grammar.
– A  A | 
 any terminal that appears in FIRST() also appears FIRST(A) because A  .
 If  is , any terminal that appears in FIRST() also appears in FIRST(A) and FOLLOW(A).

• A grammar is not left factored, it cannot be a LL(1) grammar

• A  1 | 2
any terminal that appears in FIRST(1) also appears in FIRST(2).

• An ambiguous grammar cannot be a LL(1) grammar.

CS416 Compiler Design 18

 Shift-Reduce Parsing -- Example
S  aABb input string: aaabb
A  aA | a aaAbb
B  bB | b aAbb  reduction
aABb
S

S rm
 aABb 
rm aAbb rm
 aaAbb 
rm aaabb

Right Sentential Forms

• How do we know which substring to be replaced at each reduction step?

CS416 Compiler Design 19

 Handle
• Informally, a handle of a string is a substring that matches the right side
of a production rule.
– But not every substring matches the right side of a production rule is handle

• A handle of a right sentential form  ( ) is

a production rule A   and a position of 
where the string  may be found and replaced by A to produce
the previous right-sentential form in a rightmost derivation of .
*
S
rm
 A
rm
 

• If the grammar is unambiguous, then every right-sentential form of the

grammar has exactly one handle.
• We will see that  is a string of terminals.
CS416 Compiler Design 20
 Handle Pruning
• A right-most derivation in reverse can be obtained by handle-pruning.

S=0 
rm 1 
rm 2 
rm ... 
rm n-1 
rm n= 

input string

• Start from n, find a handle Ann in n,

and replace n in by An to get n-1.
• Then find a handle An-1n-1 in n-1, and
replace n-1 in by An-1 to get n-2.
• Repeat this, until we reach S.

CS416 Compiler Design 21

 A Shift-Reduce Parser
E  E+T | T Right-Most Derivation of id+id*id
T  T*F | F E  E+T  E+T*F  E+T*id  E+F*id
F  (E) | id  E+id*id  T+id*id  F+id*id  id+id*id

Right-Most Sentential Form Reducing Production

id+id*id F  id
F+id*id TF
T+id*id ET
E+id*id F  id
E+F*id TF
E+T*id F  id
E+T*F T  T*F
E+T E  E+T
E
Handles are red and underlined in the right-sentential forms.
CS416 Compiler Design 22
 A Stack Implementation of A Shift-Reduce Parser
• There are four possible actions of a shift-parser action:

1. Shift : The next input symbol is shifted onto the top of the stack.
2. Reduce: Replace the handle on the top of the stack by the non-
terminal.
3. Accept: Successful completion of parsing.
4. Error: Parser discovers a syntax error, and calls an error recovery
routine.

• Initial stack just contains only the end-marker $.

• The end of the input string is marked by the end-marker $.

CS416 Compiler Design 23

 A Stack Implementation of A Shift-Reduce Parser
Stack Input Action
$ id+id*id$ shift
$id +id*id$ reduce by F  id Parse Tree
$F +id*id$ reduce by T  F
$T +id*id$ reduce by E  T E 8
$E +id*id$ shift
$E+ id*id$ shift E 3 + T 7
$E+id *id$ reduce by F  id
$E+F *id$ reduce by T  F T 2 T 5 * F6
$E+T *id$ shift
$E+T* id$ shift F 1 F 4 id
$E+T*id $ reduce by F  id
$E+T*F $ reduce by T  T*F id id
$E+T $ reduce by E  E+T
$E $ accept

CS416 Compiler Design 24

 Conflicts During Shift-Reduce Parsing
• There are context-free grammars for which shift-reduce parsers cannot
be used.
• Stack contents and the next input symbol may not decide action:
– shift/reduce conflict: Whether make a shift operation or a reduction.
– reduce/reduce conflict: The parser cannot decide which of several
reductions to make.
• If a shift-reduce parser cannot be used for a grammar, that grammar is
called as non-LR(k) grammar.

left to right right-most k lookhead

scanning derivation

• An ambiguous grammar can never be a LR grammar.

CS416 Compiler Design 25
 Shift-Reduce Parsers
• There are two main categories of shift-reduce parsers

1. Operator-Precedence Parser
– simple, but only a small class of grammars.
CFG
LR
LALR

2. LR-Parsers SLR
– covers wide range of grammars.
• SLR – simple LR parser
• LR – most general LR parser
• LALR – intermediate LR parser (lookhead LR parser)
– SLR, LR and LALR work same, only their parsing tables are different.

CS416 Compiler Design 26

 LR Parsers

• The most powerful shift-reduce parsing (yet efficient) is:

LR(k) parsing.

left to right right-most k lookhead

scanning derivation (k is omitted  it is 1)

• LR parsing is attractive because:

– LR parsing is most general non-backtracking shift-reduce parsing, yet it is still efficient.
– The class of grammars that can be parsed using LR methods is a proper superset of the
class of grammars that can be parsed with predictive parsers.
LL(1)-Grammars  LR(1)-Grammars
– An LR-parser can detect a syntactic error as soon as it is possible to do so a left-to-right
scan of the input.

CS416 Compiler Design 27

 LR Parsers
• LR-Parsers
– covers wide range of grammars.
– SLR – simple LR parser
– LR – most general LR parser
– LALR – intermediate LR parser (look-head LR parser)
– SLR, LR and LALR work same (they used the same algorithm),
only their parsing tables are different.

CS416 Compiler Design 28

 LR Parsing Algorithm

input a1 ... ai ... an $

stack
Sm
Xm
LR Parsing Algorithm output
Sm-1
Xm-1
.
. Action Table Goto Table
S1 terminals and $ non-terminal
s s
X1 t four different t each item is
a actions a a state number
S0 t t
e e
s s
CS416 Compiler Design 29
 (SLR) Parsing Tables for Expression Grammar
Action Table Goto Table
1) E  E+T state id + * ( ) $ E T F
0 s5 s4 1 2 3
2) ET
1 s6 acc
3) T  T*F 2 r2 s7 r2 r2
4) TF 3 r4 r4 r4 r4
5) F  (E) 4 s5 s4 8 2 3
6) F  id 5 r6 r6 r6 r6
6 s5 s4 9 3
7 s5 s4 10
8 s6 s11
9 r1 s7 r1 r1
10 r3 r3 r3 r3
11 r5 r5 r5 r5

CS416 Compiler Design 30

 Actions of A (S)LR-Parser -- Example
stack input action output
0 id*id+id$ shift 5
0id5 *id+id$ reduce by Fid Fid
0F3 *id+id$ reduce by TF TF
0T2 *id+id$ shift 7
0T2*7 id+id$ shift 5
0T2*7id5 +id$ reduce by Fid Fid
0T2*7F10 +id$ reduce by TT*F TT*F
0T2 +id$ reduce by ET ET
0E1 +id$ shift 6
0E1+6 id$ shift 5
0E1+6id5 $ reduce by Fid Fid
0E1+6F3 $ reduce by TF TF
0E1+6T9 $ reduce by EE+T EE+T
0E1 $ accept

CS416 Compiler Design 31

 Constructing SLR Parsing Tables – LR(0) Item
• An LR(0) item of a grammar G is a production of G a dot at the some
• position of the right side.
Ex: A  aBb
.
Possible LR(0) Items: .
A  aBb

..
(four different possibility)
A  aB b
A  aBb
A  a Bb

• Sets of LR(0) items will be the states of action and goto table of the SLR
parser.
• A collection of sets of LR(0) items (the canonical LR(0) collection) is
the basis for constructing SLR parsers.
• Augmented Grammar:
G’ is G with a new production rule S’S where S’ is the new starting
symbol.
CS416 Compiler Design 32
 The Closure Operation
• If I is a set of LR(0) items for a grammar G, then closure(I) is the
set of LR(0) items constructed from I by the two rules:

..
1. Initially, every LR(0) item in I is added to closure(I).
2. If A   B is in closure(I) and B is a production rule of G;
then B  will be in the closure(I).
We will apply this rule until no more new LR(0) items can be
added to closure(I).

CS416 Compiler Design 33

 The Closure Operation -- Example
.
.
E’  E closure({E’  E}) =

.
E  E+T { E’  E kernel items

.
ET E E+T

.
T  T*F E T

.
TF T T*F

.
F  (E) T F

.
F  id F (E)
F id }

CS416 Compiler Design 34

 Goto Operation
• If I is a set of LR(0) items and X is a grammar symbol (terminal or non-
terminal),
–
.
then goto(I,X) is defined as follows:
If A   X in I
.
then every item in closure({A  X }) will be in goto(I,X).

Example:
I ={ .. .. .
E’  E, E  E+T, E  T,

. . ..
T  T*F, T  F,
F  (E), F  id }

.. .
goto(I,E) = { E’  E , E  E +T }
goto(I,T) = { E  T , T  T *F }

.. . . . .
goto(I,F) = {T  F }
goto(I,() = { F  ( E), E  E+T, E  T, T  T*F, T  .
F,

.
F  (E), F  id }
goto(I,id) = { F  id }

CS416 Compiler Design 35

 Construction of The Canonical LR(0) Collection
• To create the SLR parsing tables for a grammar G, we will create the
canonical LR(0) collection of the grammar G’.

• Algorithm:
.
C is { closure({S’ S}) }
repeat the followings until no more set of LR(0) items can be added to C.
for each I in C and each grammar symbol X
if goto(I,X) is not empty and not in C
add goto(I,X) to C

• goto function is a DFA on the sets in C.

CS416 Compiler Design 36

 The Canonical LR(0) Collection -- Example
I0: E’  .E I1: E’  E.I6: E  E+.T I9: E  E+T.
E  .E+T E  E.+T T  .T*F T  T.*F
E  .T T  .F
T  .T*F I2: E  T. F  .(E) I10: T  T*F.
T  .F T  T.*F F  .id
F  .(E)
F  .id I3: T  F. I7: T  T*.F I11: F  (E).
F  .(E)
I4: F  (.E) F  .id
E  .E+T
E  .T I8: F  (E.)
T  .T*F E  E.+T
T  .F
F  .(E)
F  .id

I5: F  id.

CS416 Compiler Design 37

 Transition Diagram (DFA) of Goto Function

E + T
I0 I1 I6 I9 * to I7
F
( to I3
T
id to I4
*
to I5
F I2 I7 F
( I10
(
I3 id
to I4
E to I5
id Iid
4 T I8 )

F to I2 +
I11
I5 ( to I3
to I6
to I4
CS416 Compiler Design 38
 Constructing SLR Parsing Table
(of an augumented grammar G’)

1. Construct the canonical collection of sets of LR(0) items for G’.

C{I0,...,In}
2. Create the parsing action table as follows
• If a is a terminal, A.a in Ii and goto(Ii,a)=Ij then action[i,a] is shift j.
• If A. is in Ii , then action[i,a] is reduce A for all a in FOLLOW(A) where
AS’.
• If S’S. is in Ii , then action[i,$] is accept.
• If any conflicting actions generated by these rules, the grammar is not SLR(1).

3. Create the parsing goto table

• for all non-terminals A, if goto(I i,A)=Ij then goto[i,A]=j

4. All entries not defined by (2) and (3) are errors.

5. Initial state of the parser contains S’.S
CS416 Compiler Design 39
Parsing Tables of Expression Grammar
Action Table Goto Table
state id + * ( ) $ E T F
0 s5 s4 1 2 3
1 s6 acc
2 r2 s7 r2 r2
3 r4 r4 r4 r4
4 s5 s4 8 2 3
5 r6 r6 r6 r6
6 s5 s4 9 3
7 s5 s4 10
8 s6 s11
9 r1 s7 r1 r1
10 r3 r3 r3 r3
11 r5 r5 r5 r5

CS416 Compiler Design 40

 SLR(1) Grammar
• An LR parser using SLR(1) parsing tables for a grammar G is called as
the SLR(1) parser for G.
• If a grammar G has an SLR(1) parsing table, it is called SLR(1)
grammar (or SLR grammar in short).
• Every SLR grammar is unambiguous, but every unambiguous grammar
is not a SLR grammar.

CS416 Compiler Design 41

 shift/reduce and reduce/reduce conflicts
• If a state does not know whether it will make a shift operation or
reduction for a terminal, we say that there is a shift/reduce conflict.

• If a state does not know whether it will make a reduction operation

using the production rule i or j for a terminal, we say that there is a
reduce/reduce conflict.

• If the SLR parsing table of a grammar G has a conflict, we say that that
grammar is not SLR grammar.

CS416 Compiler Design 42

 Conflict Example
S  L=R I0: S’  .S I1:S’  S. I6:S  L=.R I9: S  L=R.
SR S  .L=R R  .L
L *R S  .R I2:S  L.=R L .*R
L  id L  .*R R  L. L  .id
RL L  .id
R  .L I3:S  R.

I4:L  *.R I7:L  *R.

Problem R  .L
FOLLOW(R)={=,$} L .*R I8:R  L.
= shift 6 L  .id
reduce by R  L
shift/reduce conflict I5:L  id.

CS416 Compiler Design 43

 Conflict Example2
S  AaAb I0: S’  .S
S  BbBa S  .AaAb
A S  .BbBa
B A.
B.

Problem
FOLLOW(A)={a,b}
FOLLOW(B)={a,b}
a reduce by A   b reduce by A  
reduce by B   reduce by B  
reduce/reduce conflict reduce/reduce conflict

CS416 Compiler Design 44

 OPERATOR GRAMMAR
• No Ɛ-transition.
• No two adjacent non-terminals.
Eg.
E  E op E | id
op  + | *
The above grammar is not an operator grammar but:
E  E + E | E* E | id
 OPERATOR PRECEDENCE

• If a has higher precedence over b; a .> b

• If a has lower precedence over b; a <. b
• If a and b have equal precedence; a =. b
Note:
– id has higher precedence than any other symbol
– $ has lowest precedence.
– if two operators have equal precedence, then we check
the Associativity of that particular operator.
 PRECEDENCE TABLE

id + * $
id .> .> .>
+ <. .> <. .>
* <. .> .> .>
$ <. <. <. .>

Example: w= $id + id * id$

$<.id.>+<.id.>*<.id.>$
 BASIC PRINCIPLE
• Scan input string left to right, try to detect .> and put a pointer on its
location.
• Now scan backwards till reaching <.
• String between <. And .> is our handle.
• Replace handle by the head of the respective production.
• REPEAT until reaching start symbol.
 EXAMPLE
STACK INPUT ACTION/REMARK
$ id + id * id$ $ <. Id
$ id + id * id$ id >. +
$ + id * id$ $ <. +
$+ id * id$ + <. Id
$ + id * id$ id .> *
$+ * id$ + <. *
$+* id$ * <. Id
$ + * id $ id .> $
$+* $ * .> $
$+ $ + .> $
$ $ accept
 DFA construction based on pattern matching
• [Link]
• [Link]

CS416 Compiler Design 50