Q.

7 To generate the quadruples, triples, and indirect triples for the expression:

(a . b) + (c + d) − (a + b + c + d)

we follow the three-address code (TAC) generation approach. The steps involve breaking the
expression into simpler subexpressions and then generating the intermediate representations.

Step 1: Break the Expression

The expression is decomposed into smaller subexpressions:

1. t1=a⋅b

2. t2=c+d

3. t3=a+b

4. t4=t3+c

5. t5=t4+d

6. t6=t1+t2

7. t7=t6−t5

Step 2: Generate Quadruples

Each row has the form (operator, arg1, arg2, result).

Step 3: Generate Triples

Each row represents the operator and the two arguments, where results are implicit.

Step 4: Generate Indirect Triples

Each row stores pointers to the original triples.

The quadruples, triples, and indirect triples efficiently represent the computation of the expression.
This breakdown ensures clarity and optimization in intermediate code generation for compilers.
Q7. To construct the syntax tree and postfix notation for the expression:

(a+(b⋅c)d−e ∣ (f+g))

Let’s analyse the expression step by step: (a+(b⋅c)d −e ∣(f+g)).

1. Operator Precedence

The operators are handled in this precedence order (highest to lowest):

1. Exponentiation (^)
2. Multiplication (⋅)
3. Addition/Subtraction (+,−+, -)
4. Bitwise OR (∣)

Parentheses override the order of operations.

2. Structure of the Expression

The expression can be grouped as:

((a+((b⋅c)d)) − e) ∣ (f+g)

3. Syntax Tree

Explanation of the Tree:

1. At the root is the ∣ operator, which joins two subtrees.

2. The left subtree evaluates (a + ((b⋅c)d) − e), with − at the root.
3. The right subtree evaluates (f + g).
4. Within the left subtree, (b⋅c) is raised to d, then added to a, followed by subtraction with e.

4. Postfix Notation

The postfix (Reverse Polish Notation) is obtained by traversing the syntax tree in postorder (left,
right, root).
Postfix of the expression:

abc⋅d+e – fg + ∣
Postfix Notation: abc⋅d+e−fg + ∣.

Q.8. Let's analyze the given grammar step by step, check if it is LR(1), and explain why it might not
be LALR(1).

Grammar

The given grammar is:

Step 1: Identify the LR(1) Properties

LR(1) Parsing

An LR(1) grammar can be parsed using an LR(1) parsing table. This table relies on a single lookahead
token to decide which production to apply based on the current state of the parse.

LR(1) Parsing Conditions:

 • No Shift/Reduce Conflicts: There should not be ambiguity between whether to shift or
reduce at any point, given the lookahead.

• No Reduce/Reduce Conflicts: There should not be ambiguity between which production to

apply when reducing, given the lookahead.

We will check for these conflicts by constructing the LR(1) items and the LR(1) parsing table.

Step 2: Compute the Canonical Collection of LR(1) Items

The canonical collection of LR(1) items for a grammar is a set of states, each containing LR(1) items.
These items represent possible configurations of the parser as it scans the input.

Start with the Initial Item Set:

The start symbol is S. We begin by computing the item set for the initial state.

1. Start with the augmented grammar:

S′→S

2. The initial set of items, I0 includes:

o S′→⋅S (the initial production with the dot at the start of S).

3. The closure of the initial item set I0I_0 is computed by including all productions that can be
derived from non-terminal symbols that appear after the dot.

o From S′→⋅S, we can add the productions for SS:

▪ S→⋅Aa

▪ S→⋅bAc

▪ S→⋅Bc

▪ S→⋅bBa

o For the productions for A and B, we add their items:

▪ A→⋅d

▪ B→⋅d

The closure of I0 contains:

Constructing the Canonical Collection of LR(1) Items:

We would continue to compute the goto function for each item in the set and generate the rest of
the item sets. This step will help us identify the states and any potential shift/reduce or
reduce/reduce conflicts.

Step 3: Check for Shift/Reduce or Reduce/Reduce Conflicts

After constructing the LR(1) parsing table from the item sets, we can check for shift/reduce conflicts
and reduce/reduce conflicts.

• Shift/Reduce Conflict: This occurs if the parser, based on the current state and lookahead
token, cannot decide whether to shift (move to a new state) or reduce (apply a production).

• Reduce/Reduce Conflict: This happens if there are multiple possible productions to apply
during a reduction, and the parser cannot decide which one to apply based on the
lookahead.

Step 4: Check if the Grammar is LALR(1)

An LALR(1) grammar is a more restricted version of an LR(1) grammar. It only differs in how the
parsing table is constructed, specifically in how the states are merged in the LALR(1) construction
process.

• LALR(1) Parsing: After constructing the LR(1) parsing table, the LALR(1) parsing table merges
equivalent states (states that have the same items but possibly different lookaheads).

• If the merging of states introduces shift/reduce or reduce/reduce conflicts, the grammar is

not LALR(1).

Potential Conflict in the Grammar:

• The key part of this grammar is the productions for

• After merging the states in the LALR(1) construction, it is likely that a shift/reduce conflict
arises when parsing the input starting with b. Both bAc and bBa start with the same terminal
bb, and in the LALR(1) table, they may merge into the same state. This causes ambiguity
since the parser cannot distinguish between these two alternatives when both are in the
same state and the lookahead is aa or c.

• LR(1) Parsing: The grammar is LR(1) because, when using the LR(1) parsing table, we can
successfully parse the input without any shift/reduce or reduce/reduce conflicts.
 • LALR(1) Parsing: The grammar is not LALR(1) because, when constructing the LALR(1) table
(which involves merging states with identical items), we encounter a shift/reduce conflict
due to the two productions S→bAc and S→bBa merging into the same state.

This conflict arises in the process of merging states in LALR(1) parsing, as the parser cannot resolve
which production to apply when it encounters a b followed by a non-terminal. Hence, the grammar is
LR(1) but not LALR(1).

Q11. Let's first analyze the given grammar and verify whether it is LL(1), and then parse the input
string "ba".

Grammar

S→AaAb∣BbBa

A→ϵ

B→ϵ

Step 1: Verify if the Grammar is LL(1)

For a grammar to be LL(1), the following two conditions must be met for each non-terminal NN:

1. First Condition (First Sets): The First sets of the right-hand sides of the production rules for a
non-terminal must be disjoint. That is, there should be no intersection between the sets of
terminals that can start each production rule.
 2. Second Condition (Follow Sets): If one of the production rules is nullable (i.e., produces
ϵ\epsilon), the intersection of the Follow set of the non-terminal with the First set of the
right-hand side of the other production should be empty.

First Step: Calculate the First Sets

• First(S):

o For the production S→AaAb, since A→ϵ, S→AaAb can start with a. Thus, First(S)
includes a.

o For the production S→BbBa, since B→ϵ S→BbBa can start with b. Thus, First(S)
includes b.

o Therefore, First(S) = {a, b}.

• First(A):

o A→ϵ, so First(A) = { ϵ }.

• First(B):

o B→ϵ, so First(B) = { ϵ }.

Second Step: Calculate the Follow Sets

• Follow(S):

o Since SS is the start symbol, Follow(S) = { $ } (where $ represents the end of input).

• Follow(A):

o From the production S→AaAb is followed by a. So, Follow(A) = { a }.

• Follow(B):

o From the production S→BbBa, B is followed by b. So, Follow(B) = { b }.

Check the LL(1) Condition

• For the non-terminal SS, the two production rules are:

1. S→AaAb

2. S→BbBa

The First sets for these two productions are:

o First(AaAb) = {a}

o First(BbBa) = {b}

Since {a} and {b} are disjoint, there is no conflict, and the grammar satisfies the First condition.

• For the nullable non-terminals A and B, we also need to ensure that there is no conflict in the
Follow sets:

o Since A is nullable and is followed by a in the production S→AaAb, we check the

Follow(A) and First(S) sets.
 ▪ Follow(A) = {a}, and First(S) = {a, b}.

▪ There's no overlap between the follow set and the first set in the second
rule, so no conflict.

o Similarly, since B is nullable and is followed by b in the production S→BbBa, we

check the Follow(B) and First(S) sets.

▪ Follow(B) = {b}, and First(S) = {a, b}.

▪ There's no overlap between the follow set and the first set of the first
production, so no conflict.

Since both the First and Follow conditions are satisfied, the grammar is LL(1).

Step 2: Parse the Input String "ba"

Now, let's parse the input string "ba" using the LL(1) parsing technique.

Parse Table

To construct the LL(1) parse table, we need to fill it based on the First and Follow sets.

• For S:

o If the lookahead token is a, we use the production S→AaAb

o If the lookahead token is b, we use the production S→BbBaa.

Parsing Steps for Input "ba"

1. Initial Stack: S

o Input: "ba"

o Action: The top of the stack is S, and the lookahead is b.

o According to the parse table, if the lookahead is b, we apply S→BbBa.

o Stack after applying the production: B,B,aB, B, a

o Input: "ba"

2. Next Step: The top of the stack is B, and the lookahead is b.

o Using the production B→ϵ (since B is nullable), we pop B from the stack.
 o Stack after applying the production: B,aB, a

o Input: "ba"

3. Next Step: The top of the stack is B, and the lookahead is b.

o Again, using B→ϵ, we pop B from the stack.

o Stack after applying the production: aa

o Input: "ba"

4. Next Step: The top of the stack is aa, and the lookahead is b.

o We encounter a mismatch (expected a, but the input is b), indicating a parsing error.

Thus, the input "ba" cannot be parsed correctly with this grammar, as the lookahead token does not
match the expected terminal at one of the parsing steps.

Q24. Same as Q10.

Q3. Let's break down the given statement:

void main ( )
{
int x; x = 3;
}

Step-by-step Tokenization:

To find the tokens, we'll analyze the statement and identify each individual component (identifier,
keyword, operator, punctuation, etc.).
1. void

o Type: Keyword

o Value: void

2. main

o Type: Identifier

o Value: main

3. (

o Type: Punctuation

o Value: (

4. )

o Type: Punctuation

o Value: )

5. {

o Type: Punctuation

o Value: {

6. int

o Type: Keyword

o Value: int

7. x

o Type: Identifier

o Value: x

8. ;

o Type: Punctuation

o Value: ;

9. x

o Type: Identifier

o Value: x

10. =

o Type: Operator

o Value: =

11. 3
 o Type: Constant (Integer)

o Value: 3

12. ;

o Type: Punctuation

o Value: ;

13. }

o Type: Punctuation

o Value: }

Final Token Count:

• Number of Tokens: 13

• Token Types and Values:

o Keywords: 2 (void, int)

o Identifiers: 3 (main, x, x)

o Operators: 1 (=)

o Constants: 1 (3)

o Punctuation: 5 ((, ), {, ;, })

Thus, the given code contains 13 tokens.

Q26. Let's break down the phases of a typical compiler and understand what happens during each
phase when compiling the C code fragment:

Position = initial + rate * 60;

1. Lexical Analysis (Scanning)

The lexical analyzer (scanner) reads the source code and converts it into a stream of tokens. These
tokens represent keywords, identifiers, constants, operators, punctuation, etc.

Input:

Position = initial + rate * 60;

Tokens Produced:

• Position: Identifier

• =: Assignment operator
 • initial: Identifier

• +: Addition operator

• rate: Identifier

• *: Multiplication operator

• 60: Constant (Integer)

• ;: Semicolon (Punctuation)

The output of the lexical analysis phase is a list of tokens.

2. Syntax Analysis (Parsing)

The syntax analyzer (parser) takes the token stream produced by the lexical analyzer and checks if
the sequence of tokens follows the rules of the language's grammar.

Grammar Used:

• Assignment: identifier=expression;\text{identifier} = \text{expression};

• Expression: identifier+identifier∗constant\text{identifier} + \text{identifier} * \text{constant}

For the statement Position = initial + rate * 60;, the parser will identify that:

• Position is an identifier (left-hand side of the assignment).

• The expression on the right-hand side is initial + rate * 60, which involves an addition and a
multiplication operation.

Syntax Tree:

The syntax tree produced by the parser would look like this:

/\

Position +

/ \

initial *

/\

rate 60

Here:

• The root is the assignment operator (=).

• The left child is the identifier Position.

 • The right child is the addition (+), with initial as the left operand and the multiplication (*) as
the right operand.

• The multiplication (*) has rate and 60 as operands.

3. Semantic Analysis

In the semantic analysis phase, the compiler checks whether the program makes sense logically. It
ensures that variables are declared before they are used, types match, and operations are valid.

• Position, initial, and rate must be declared as variables (likely of numeric type such as int or
float).

• The operation rate * 60 is valid as both rate and 60 are numeric types.

• The result of initial + rate * 60 will be assigned to Position, and the types of Position and the
result must be compatible (e.g., both should be of type int or float).

If any semantic error occurs (e.g., if Position is not declared), the compiler would flag it here.

4. Intermediate Code Generation

In the intermediate code generation phase, the compiler converts the high-level language into a
lower-level intermediate code. This intermediate code typically uses a more basic set of instructions.

For this C statement, the intermediate code might look like something akin to:

t1 = rate * 60

t2 = initial + t1

Position = t2

Here:

• t1 stores the result of rate * 60.

• t2 stores the result of initial + t1.

• Finally, the value of t2 is assigned to Position.

This intermediate code is easier for the compiler to optimize and translate into machine code.

5. Optimization

During optimization, the compiler may try to improve the performance of the generated
intermediate code.

For this expression, there may not be significant optimizations, but the compiler could:

• Combine operations (e.g., precompute rate * 60 if rate is constant).

• Use registers efficiently or minimize memory access.

The output of this phase would still be similar to the intermediate code but potentially optimized for
efficiency.

6. Code Generation
In the code generation phase, the compiler translates the intermediate code into assembly or
machine code specific to the target platform. Here’s an example of how the code could be translated
into assembly language:

MOV R1, rate ; Load rate into register R1

MOV R2, 60 ; Load constant 60 into register R2

MUL R1, R2 ; Multiply rate and 60, result in R1

ADD R3, initial, R1 ; Add initial and R1, result in R3

MOV Position, R3 ; Store the result from R3 into Position

Here:

• Registers (e.g., R1, R2, R3) are used for holding intermediate values.

• MOV is used for moving values between registers and memory.

• MUL performs multiplication, and ADD performs addition.

7. Code Optimization (Target-Specific)

During this phase, the compiler performs low-level optimizations, like:

• Register allocation: Choosing the best registers to store variables.

• Instruction reordering: Reordering instructions for better CPU cache utilization.

For instance, if rate is a constant, the multiplication could be precomputed to avoid the need for the
multiplication instruction at runtime.

8. Code Emission

Finally, code emission generates the final executable file, whether in assembly, machine code, or
bytecode format.

Summary of Output at Each Phase

1. Lexical Analysis (Tokenization):

o Tokens: Position, =, initial, +, rate, *, 60, ;

2. Syntax Analysis (Parsing):

/\

Position +

/ \

initial *
 /\

rate 60

3. Semantic Analysis:

o Checks that all identifiers are declared and used correctly, types match.

4. Intermediate Code Generation:

5. t1 = rate * 60

6. t2 = initial + t1

7. Position = t2

8. Optimization:

o Potential optimizations, like combining computations if possible.

9. Code Generation (Assembly):

10. MOV R1, rate

11. MOV R2, 60

12. MUL R1, R2

13. ADD R3, initial, R1

14. MOV Position, R3

15. Code Optimization (Target-Specific):

o Further optimization of instructions for performance.

16. Target Code Generation:

o Final executable or machine code produced.