Name – Vikas Yadav Sec0on - G

Reg No. – RA2211003030017

Assignment 1

Compiler Design

Q1- Explain How Finite automata are useful in the lexical analysis?

A - Finite automata play a crucial role in lexical analysis, which is the first phase of a
compiler. Lexical analysis involves scanning the input source code and converting it into a
sequence of tokens that can be used by the syntax analyzer. Here's how finite automata are
useful in lexical analysis:

1. Token Recognition

• Lexical analyzers use finite automata (FA) to identify tokens such as keywords,
identifiers, operators, literals, and special symbols.
• Example: The word int in C programming is recognized as a keyword, while x is
identified as an identifier.

2. Regular Expressions and FA

• The rules for token patterns are often written using regular expressions.
• These regular expressions are then converted into finite automata (either deterministic
finite automata (DFA) or nondeterministic finite automata (NFA)) to efficiently scan
the input.

3. Efficient Scanning and Matching

• A DFA-based lexical analyzer can recognize tokens in a single pass over the input,
making it fast and efficient.
• Example: The input string "if (x == 10)" is scanned and matched with token
patterns using FA.

4. Handling Whitespaces and Comments

• Finite automata can also be used to ignore unwanted characters like spaces, tabs, and
comments, ensuring that only meaningful tokens are passed to the parser.

5. Error Detection

• If an input does not match any valid token pattern, FA helps in error detection,
allowing the compiler to report lexical errors.
6. Transition Tables for Lexical Analysis

• The lexical analyzer uses transition tables generated from FA to determine the next
state based on the current state and input character.

Example: DFA for Identifiers

A DFA for recognizing an identifier (variable name) in C (starting with a letter followed by
letters or digits) can be structured as:

1. Start State (q0) → Read a letter → Move to state q1.

2. State q1 → Read a letter or digit → Stay in q1.
3. Final State (q1) → If a non-letter/digit is encountered, return identifier token.

Q2 - Define Cross Compiler with the help of an example

A - A Cross Compiler is a compiler that runs on one machine (host) but generates executable
code for a different machine (target). It is used when the target system has different hardware
or operating system constraints.

Example:

Suppose you are developing an embedded system for an ARM-based microcontroller on a

Windows PC. Since the microcontroller cannot run a compiler itself, you use a cross compiler
on your Windows PC to generate code for the ARM processor.

• Host System: Windows (x86)

• Target System: ARM-based microcontroller
• Cross Compiler: arm-none-eabi-gcc (used for compiling C code for ARM)

Thus, a cross compiler helps in software development for different architectures without
needing to compile code directly on the target device.
Q3 - Differen0ate between compilers and interpreters ?

A-

Feature Compiler Interpreter

Execution Translates the entire source code into Translates and executes code line by
Method machine code at once. line.
Faster, as execution happens after Slower, as it translates while
Speed
complete translation. executing.
Detects all errors at once after Detects errors line by line, stopping
Error Handling
compilation. at the first error.
Generates an independent executable Does not create a separate
Output
file. executable; runs the code directly.
Example Python, JavaScript (interpreted
C, C++ (compiled languages)
Languages languages)
Best for performance-critical Useful for scripting, debugging, and
Use Case
applications. dynamic execution.

Example:

• C Compiler (gcc): Converts the whole C program into an executable.

• Python Interpreter (python): Executes Python code line by line.

Thus, compilers are better for speed and efficiency, while interpreters offer flexibility and
ease of debugging.

Q4 - Write short notes on :

i. Input buffering scheme

ii. How do you change the basic Input buffering algorithm to achieve beRer performance?

A - (i) Input Buffering Scheme

Input buffering is a technique used in lexical analysis to reduce the number of I/O operations
while scanning the source code. Since reading from disk is slow, buffering improves
performance by reading the input in large chunks instead of character by character.

Two-Buffer Scheme

• The input is divided into two buffers, each of a fixed size (e.g., 4KB each).
• The lexical analyzer processes one buffer while the second buffer is filled in the
background.
• This allows for overlapping computa0on and I/O, reducing delays.
Advantages:

1. Reduces I/O opera0ons, improving efficiency.

2. Handles large input files efficiently.
3. Uses sen0nel markers to detect the end of a buffer without extra checks.

(ii) Improving the Basic Input Buffering Algorithm

The basic input buffering algorithm can be enhanced for better performance using the
following techniques:

1. Use of Lookahead Buffers

o Instead of reading one character at a 0me, prefetch mul0ple characters and
allow lookahead.
o Helps in token recogni0on (e.g., dis0nguishing == from =).
2. Double Buffering (Two-Buffer Scheme)
o As men0oned earlier, using two buffers allows I/O and computa0on to
overlap.
3. Efficient Buffer Management with Circular Buffers
o Instead of reloading en0re buffers, a circular buffer allows seamless reading.
o Avoids unnecessary copying of data.
4. Memory-Mapped Files
o Instead of explicit buffering, memory-mapped I/O allows direct access to file
content in memory.
5. Minimizing Unnecessary Backtracking
o Using finite automata with efficient state transi0ons reduces excessive
backtracking while scanning tokens.

Conclusion

Improving input buffering optimizes lexical analysis by reducing disk I/O, improving
memory management, and enabling faster lookahead and token recognition.

Q5 - Discuss the Func0ons of Lexical Analyzer. Explain LEX tool.

A - Functions of Lexical Analyzer

A Lexical Analyzer (also called a Scanner) is the first phase of a compiler that processes
source code and converts it into tokens. Its main functions are:

1. Tokenization:
o Recognizes keywords, iden0fiers, literals, operators, and special symbols in
the source code.
o Example: int x = 10; → Tokens: int, x, =, 10, ;
 2. Ignoring Whitespaces & Comments:
o Skips unnecessary spaces, tabs, newlines, and comments to improve
efficiency.
3. Error Detection:
o Iden0fies invalid tokens and reports lexical errors.
o Example: @var = 5; → Error: Invalid symbol @
4. Interaction with Symbol Table:
o Stores iden0fiers and keywords in a symbol table for easy reference during
syntax and seman0c analysis.
5. Lookahead Handling:
o Supports lookahead buffering to differen0ate between similar tokens, e.g.,
dis0nguishing = and ==.

LEX Tool (Lexical Analyzer Generator)

LEX is a tool used to generate lexical analyzers automatically based on regular expressions.

How LEX Works:

1. Define Token Patterns:

o Write rules using regular expressions (e.g., int for recognizing integers).
2. Generate a Lexical Analyzer:
o LEX converts the rules into C code that can be compiled.
3. Token Recognition & Processing:
o The generated lexer scans input and returns tokens for further processing.

Advantages of LEX:

Automates the lexical analysis process

Supports regular expressions for token matching
Works efficiently with YACC (Yet Another Compiler Compiler) for parsing

Thus, LEX simplifies lexical analysis, making compiler design easier.

Q- 6 Design NFA for the regular expression ( X+Y) *XYY using Thompson Construction
rule.

A- To construct an NFA (Nondeterminis0c Finite Automaton) using Thompson’s Construc0on

for the given regular expression (X + Y) * XYY –

Step 1: Break Down the Regular Expression

The given expression (X + Y) * XYY consists of:

1. (X + Y)* → This denotes zero or more repetitions of either X or Y.

2. XYY → A fixed sequence of X, followed by Y, followed by another Y.
Step 2: Construct Individual NFAs

(i) Construct NFA for X + Y (Union)

According to Thompson’s Construction, the NFA for X + Y is:

(ε) --> (X) --> (ε)

| |
(ε) --> (Y) --> (ε)

Here, ε-transitions are used to allow non-determinism.

(ii) Construct NFA for (X + Y)*

To apply the Kleene star (*), add:

1. A new start state with an ε-transi0on to the original NFA.

2. An ε-transi0on from the final state back to the start state.
3. Another ε-transi0on to a new final state, allowing empty string acceptance.

--> (ε) --> (X) --> (ε) -->

| | |
--> (ε) --> (Y) --> (ε) --> *

(iii) Construct NFA for XYY (ConcatenaJon)

For the fixed sequence XYY, apply concatenation:

--> (X) --> (Y) --> (Y) -->

Step 3: Combine NFAs

Now, concatenate (X + Y) NFA* with XYY NFA using ε-transitions:

Start --> (ε) --> (X + Y)* --> (X) --> (Y) --> (Y) --> Final

• The (X + Y)* part allows repetition of X and Y before XYY.

• ε-transitions connect the two parts smoothly.

Final NFA Diagram Representation

+-------------------------------+
| |
--> (ε) --> (X) --> (ε) --> (X) --> (Y) --> (Y) --> Final
| | |
--> (ε) --> (Y) --> (ε)
| |
+--------------------------------+
Q- 7 Construct a DFA for the following expression (a+b)*a(a+b).

A- To construct a DFA (Deterministic Finite Automaton) for the given regular expression
(a+b)*a (a + b)-

Step 1: Breakdown of the Expression

• (a + b)* → Any sequence (including empty) of a or b.

• a (a + b) → Ends with an a followed by either a or b.

Step 2: Identify States & Transitions

We need a DFA that accepts all strings ending with a(a + b).

State DefiniJons

1. q0 (Start State) → Accepts any number of a or b.

2. q1 → Aier seeing an a, move here (ensuring a exists before final a/b).
3. q2 (Final State) → Aier seeing a(a + b), the string is accepted.

State TransiJons

• From q0, if a appears → go to q1.

• From q0, if b appears → stay in q0 (since we s0ll need a).
• From q1, if a or b appears → go to q2 (as it forms a(a + b)).
• From q2, if a or b appears → stay in q2 (since a valid suffix is already seen).

Step 3: DFA Transition Table

State Input a Input b

q0 (Start) q1 q0
q1 q2 q2
q2 (Final) q2 q2

Step 4: DFA Diagram Representation

→ (q0) --a--> (q1) --a/b--> (q2)

| ↑
b |
| |
v |
(q0) -------------------

q2 is the final state (accepts valid strings).

Step 5: Example Accepted Strings

aa
ba
aba
baba
abba
bbba

This DFA ensures that a string is accepted if and only if it contains at least one "a" followed
by either "a" or "b" at the end.

Q- 8 Write algorithm for conversion of NFA to DFA.

A - The process of converting a Nondeterministic Finite Automaton (NFA) to a Deterministic

Finite Automaton (DFA) involves creating a new DFA that simulates the behavior of the
given NFA. This process is often called subset construction or powerset construction.

Steps for NFA to DFA Conversion:

1. Start with the NFA:

o Given NFA states and transi0ons.
o Iden0fy the start state and final states of the NFA.
2. Create a DFA Start State:
o The start state of the DFA is the epsilon closure of the NFA’s start state.
o The epsilon closure of a state includes all states that can be reached from it
using epsilon (empty) transi0ons.
3. Iterate Over All Possible NFA State Combinations:
o Treat each combina0on of NFA states (from the epsilon closure) as a single
state in the DFA.
o For each DFA state, calculate the possible transi0ons for each input symbol.
4. Create Transitions:
o For each state in the DFA, calculate where each input symbol (a, b, etc.) takes
you in the NFA.
o Use the epsilon closure again to handle possible epsilon transi0ons aier the
symbol is processed.
5. Final States:
o Any DFA state that contains an NFA final state is considered a final state in the
DFA.
6. Repeat the Process:
o Repeat steps 3-5 un0l all reachable DFA states are processed and no new
states can be added.
7. Minimize the DFA (Optional):
o Aier construc0ng the DFA, you may reduce redundant states if needed for
op0miza0on.
Q – 9 Differentiate between phases and passes of compiler.

A- Phases of a Compiler:

A phase in a compiler refers to a logical step in the compilation process. Each phase performs
a specific task or transformation on the source code. The main purpose of each phase is to
handle one aspect of the compilation, such as checking syntax, generating intermediate code,
or optimizing the code.

Common phases in a compiler include:

1. Lexical Analysis: Converts the source code into tokens (keywords, identifiers,
operators, etc.).
2. Syntax Analysis: Analyzes the syntax of the source code and builds a parse tree or
abstract syntax tree (AST).
3. Semantic Analysis: Checks for semantic errors, such as type mismatches or
undeclared variables.
4. Intermediate Code Generation: Converts the parse tree into an intermediate code
(often platform-independent).
5. Optimization: Improves the intermediate code for better efficiency, like removing
redundant code.
6. Code Generation: Converts optimized intermediate code into machine code or
assembly code.
7. Code Emission: Outputs the final machine code or assembly code ready for execution.

The phases happen in sequence during the compilation process, each performing a specific
function on the code. Phases do not reprocess the same input; they handle distinct stages of
code transformation.

Passes of a Compiler:

A pass refers to a complete traversal or iteration over the source code (or intermediate code).
In some compilers, the same phase might need to process the code multiple times, known as
multiple passes. Each pass may execute one or more phases.

For example, in a multi-pass compiler:

1. The first pass might handle lexical analysis and syntax analysis, producing a parse
tree.
2. A subsequent pass could focus on semantic analysis and generate intermediate code.
3. Further passes might perform optimizations or code generation.

Each pass involves reprocessing parts of the code that may have been transformed in the
previous pass. For instance, after performing lexical analysis, a second pass might perform
semantic analysis on the tokens produced in the first pass.

A single-pass compiler, on the other hand, processes the code only once, completing all
necessary phases in a single traversal of the source code.
Key Differences:

• Phases are logical steps in the compilation process, such as lexical analysis, syntax
analysis, or code generation. These phases are fixed and happen in a set sequence.
• Passes refer to iterations or traversals of the input code. In multi-pass compilers,
several passes are needed, where each pass processes the code multiple times to refine
it or gather more information.

Phases perform different tasks at each stage of the compilation, while passes represent how
many times the compiler iterates through the source code or intermediate code to complete
the task.

In simple terms, phases are the specific tasks of a compiler, while passes are the repetitions of
those tasks during the compilation process.

Q – 10 Check whether given grammar is ambiguous or not. If ambiguous , convert it into

unambiguous grammar.

E→E+E

E→E*E

E → ID

A- To check whether the given grammar is ambiguous or not, we need to see if there exists
more than one leftmost derivation or more than one parse tree for a particular string.

Given Grammar:

E → E + E
E → E * E
E → ID

This is a typical example of a grammar for arithmetic expressions, but it may be ambiguous
due to the possibility of different interpretations of operator precedence.

Step 1: Check if the Grammar is Ambiguous

Consider the string:

ID + ID * ID

Let’s try to derive this string using the given grammar.

LeNmost DerivaJon 1 (TreaJng + first):

E
→ E + E
→ E + E * E (Using E → E * E)
→ ID + E * E (Using E → ID)
→ ID + ID * E (Using E → ID)
→ ID + ID * ID (Using E → ID)
LeNmost DerivaJon 2 (TreaJng * first):
E
→ E + E
→ E + E * E (Using E → E * E)
→ E + ID * E (Using E → ID)
→ ID + ID * E (Using E → ID)
→ ID + ID * ID (Using E → ID)

In both derivations, we end up with the same string ID + ID * ID, but the order of
applying rules is different, meaning the interpretation of the operations is different. This
indicates that the grammar can generate multiple parse trees for the same input, which
implies that the grammar is ambiguous.

Step 2: Make the Grammar Unambiguous

To remove the ambiguity, we need to clarify the operator precedence in the grammar. The
standard way is to define multiplication (*) as having higher precedence over addition (+).

We can do this by restructuring the grammar as follows:

1. Handle multiplication first:

We introduce a new non-terminal that deals with expressions involving multiplication
first.
2. Left recursion for +:
We keep the left recursion for the addition operator (+).

Unambiguous Grammar:

Let’s define two non-terminals to separate the handling of + and *:

E → T + E | T
T → F * T | F
F → ID

Here:

• E represents an expression with addi0on.

• T represents terms involving mul0plica0on.
• F represents the basic unit, which in this case is ID.

ExplanaJon:

• T handles the mul0plica0on (*), ensuring that mul0plica0on is evaluated before

addi0on.
• E handles the addi0on (+), allowing for lei recursion on addi0on.
Now let's check the derivation for ID + ID * ID:

1. Using E → T + E:

E → T + E
→ F * T + E (Using T → F * T)
→ ID * F + E (Using F → ID)
→ ID * ID + E (Using F → ID)
→ ID * ID + F (Using E → T)
→ ID * ID + ID (Using F → ID)

This clearly shows the correct precedence (multiplication before addition), and there is only
one unique parse tree.

Thus, the new grammar is unambiguous.