CS 160
Transformation of Programming Languages
Discussion 1
William Eiers & Seemanta Saha
TA Details
William Eiers Seemanta Saha
weiers@[Link] seemantasaha@[Link]
Office Hour : Office Hour :
Monday 3pm to 4pm Wednesday 3pm to 4pm
Thursday 3pm to 4pm Thursday 11am to 12pm
Place : TA Trailer 936, 103-104 Place : TA Trailer 936, 103-104
TA Trailer Location
Details
● Website: [Link]
● Main focus on building compiler
● Coding projects
● We will use C++, Flex, Bison, and Intel Assembly
● Prefer to use GDB as debugging tool
● C++ knowledge is prerequisite
Goal
● We are going to implement a real compiler
● We will go through the process of building a compiler and
the tools most often used during this process
● Eventually, this course will lead us to create a large and
diverse software system
Projects
● Projects cover 50% of grade.
● 5% Project 1, 15% Project 2, 15% Project 3, 20% Project
4, 22.5% Project 5, 22.5% Project 6.
● Project 1 and 2 are stand-alone C++ projects
● Projects 3, 4, 5, and 6 will form a real compiler
○ Will compile a simple language
○ Each project represents a stage of compilation
Project 1
● Goal: learn tools and design patterns you need to use for
the course
● Consists of three steps:
○ Join the course on Piazza
○ Get started with GDB
○ Write two visitors for a tree structure
Project 2
● Goal: get familiar with writing scanner and parser
● Input will be a simple language consisting of:
○ Integer arithmetic expressions
○ Memory variables and print statements
○ Will parse and evaluate a correct program
○ Will output an error for an incorrect program
Project 3
● Lexical and Syntax Analysis
○ Lexer (built with Flex) & parser (built with Bison)
Project 4
● Abstract Syntax Tree
○ Bison actions and attribute grammar
Project 5
● Semantic Analysis
○ Type checking
Project 6
● Code Generation
○ Generate executable code
○ Intel x86 Assembly
Worried?
istockphoto
Course Website
Post on Lectures and
Piazza Discussions
Office Hours
[Link]
Project Testing and Grading
● Test cases are included with the project files
● Always run your solution on these cases
● Will give you a very strong idea of your score
● You may want to write additional test cases to further
verify the correctness of your solution
Project 1
Enroll yourself as a student for
CS 160
Debugger Review
● The debugger is extremely helpful in this course
● We will work with complicated C++ programs
● We will write x86 assembly which works with memory
directly
● Most common debugger is gdb
● The LLVM debugger (Mac OS X) is called lldb
GDB (Gnu Debugger)
● Standard debugger for Linux operating systems
● Supports a wide variety of languages such as C++
● We can put breakpoint, trace back to the execution
sequence, print memory variables using GDB
● Once we run a GDB session for an executable, we can
easily debug it using various commands supported by
GDB
GDB Useful Commands
● gdb ./executableName to run an executable using GDB
● run to run the program inside the debugger at the gdb prompt.
● bt will run a backtrace, which will show you full call stack at this point
including all arguments to functions
● p x to print the value of variable x
● break functionName to set a breakpoint at the beginning of the function
functionName
● break [Link]:linenum set breakpoints for specific statements
● clear functionName to clear a breakpoint
● quit to quit from GDB prompt
Pointer Review
● Variable which points to another location
● Value is a memory address
● Can point to an object or a basic data type
● In C++, the pointer type gives information about what type
of data it points to
● For example an int * (usually!) points to an int
Pointer Review (contd.)
● You can cast a pointer to a different type:
int *p; float *q = (float *)p;
● This means that we are going to treat the value that p
points to as a float instead of an int
● This is useful when working with class inheritance
● Can cast a child class pointer to parent class pointer,
every child is also instance of parent
Visitor Pattern
● A way to separate an algorithm from data structure on
which it operates
● Useful when traversing a possibly complex structure
● Keeps the structure unchanged
● The visitor models processes in itself
Project 1 and Visitor Pattern
● Data Structure : Tree
● Implemented Visitor: Print
● Partially Implemented Visitor: Sum
● Not Implemented Visitor: Max
● Our data structure (Tree) is visitable and It accepts
visitor
Let’s see in Project1 code
Data Structure : Tree
class Node : Visitable {
public:
int value;
std::vector<Node*> children;
Node(int newValue) : value(newValue) {}
void visit_children(Visitor* v) {
for (std::vector<Node*>::iterator it = this->[Link]();
this->[Link](); it++) {
(*it)->accept(v);
}
}
void accept(Visitor* v) {
v->visitNode(this);
}
};
Visitors
● We have a visitor base class which has a definition of
visitNode method
● Whenever we need a new feature, we will add a new
visitor which will extend this base class and implement
visitNode method
● Implementation of visitNode method will be different
according to our feature requirement
Visitors (contd.)
● Important to remember:
○ You choose whether the visitor is going to go on exploring the
children nodes or do some calculation on the parent first, by
calling visit_children() properly!
○ For example, Print visitor first prints the current node and then
visits children
void PrintVisitor::visitNode(Node* node){
std::cout<<node->value<<" ";
node->visit_children(this);
}
Construction of Tree
input : (1 (2 (3)) (4) (5 (6) (7)))
output tree :
1
2 4 5
Let’s see the
3 6 7 construction on
white board
