CPSC 411, 2015W Term 2 Midterm Exam Date: February 25, 2016; Instructor: Ron Garcia

Similar documents
CPSC 411, Fall 2010 Midterm Examination

CPSC 311, 2010W1 Midterm Exam #2

Question Marks 1 /20 2 /16 3 /7 4 /10 5 /16 6 /7 7 /24 Total /100

UNIVERSITY REGULATIONS

Announcements. Project 2: released due this sunday! Midterm date is now set: check newsgroup / website. Chapter 7: Translation to IR

The University of British Columbia Final Examination - December 02, 2014 Mathematics 308. Closed book examination. No calculators.

Question Marks 1 /11 2 /4 3 /13 4 /5 5 /11 6 /14 7 /32 8 /6 9 /11 10 /10 Total /117

Question Marks 1 /16 2 /13 3 /12 4 /15 5 /8 6 /15 7 /8 8 /5 9 /8 Total /100

UNIVERSITY REGULATIONS

Question Marks 1 /12 2 /6 3 /14 4 /8 5 /5 6 /16 7 /34 8 /25 Total /120

Administration. Today

CPSC 320 Midterm 2. July 13, 2007

CS 411 Midterm Feb 2008

CPSC 121 Midterm 1 Friday October 14th, Signature: Section (circle one): 11:00 15:30 17:00

Full Name: CS Account:

THE UNIVERSITY OF BRITISH COLUMBIA CPSC 261: MIDTERM 1 February 14, 2017

CPSC 121 Some Sample Questions for the Final Exam Tuesday, April 15, 2014, 8:30AM

THE UNIVERSITY OF BRITISH COLUMBIA CPSC 110: MIDTERM 1 Part B May 26, Important notes about this examination

MARKING KEY The University of British Columbia MARKING KEY Computer Science 260 Midterm #1 Examination 12:30 noon, Tuesday, February 14, 2012

CPSC 121 Sample Final Examination December 2013

MARKING KEY The University of British Columbia MARKING KEY Computer Science 260 Midterm #2 Examination 12:30 noon, Thursday, March 15, 2012

CPSC 311, 2011W1 Midterm Exam #2 2011/11/09

The University of Oregon May 16, 2015 Oregon Invitational Mathematics Tournament:

Compilers. Compiler Construction Tutorial The Front-end

EXAMINATION INSTRUCTIONS

EXAMINATION INSTRUCTIONS

This examination has 11 pages. Check that you have a complete paper.

EXAMINATION INSTRUCTIONS

THE UNIVERSITY OF BRITISH COLUMBIA CPSC 121: MIDTERM 2 Group March 12, 2014

CPSC 121 Midterm 1 Friday February 5th, Signature: Section (circle one): Morning Afternoon

We ve written these as a grammar, but the grammar also stands for an abstract syntax tree representation of the IR.

Examination in Compilers, EDAN65

The University of Oregon May 16, 2015 Oregon Invitational Mathematics Tournament:

1 Lexical Considerations

7 Translation to Intermediate Code

Compiler Internals. Reminders. Course infrastructure. Registering for the course

Lexical Considerations

Intermediate Representations

Parsing II Top-down parsing. Comp 412

Lexical Considerations

2.2 Syntax Definition

CIS 341 Midterm February 28, Name (printed): Pennkey (login id): SOLUTIONS

CPSC 410 Advanced Software Engineering Mid-term Examination (Term I ): Solution Instructor: Gail Murphy

Where we are. What makes a good IR? Intermediate Code. CS 4120 Introduction to Compilers

Topic 3: Syntax Analysis I

EXAMINATION INSTRUCTIONS

Projects for Compilers

COMP-421 Compiler Design. Presented by Dr Ioanna Dionysiou

CS164: Midterm I. Fall 2003

MATH 253/101,102,103,105 Page 1 of 12 Student-No.:

CS 132 Compiler Construction

Computer Science 304

CMSC 330: Organization of Programming Languages. Formal Semantics of a Prog. Lang. Specifying Syntax, Semantics

UNIVERSITY REGULATIONS

CSE P 501 Exam 8/5/04

An Introduction to Functions

LECTURE 3. Compiler Phases

The University of British Columbia Computer Science 304 Practice Final Examination

DEMO A Language for Practice Implementation Comp 506, Spring 2018

Context-free grammars (CFG s)

Context-Free Grammar. Concepts Introduced in Chapter 2. Parse Trees. Example Grammar and Derivation

CPSC 411: Introduction to Compiler Construction

Comp 311: Sample Midterm Examination

Topic 7: Intermediate Representations

Types and Static Type Checking (Introducing Micro-Haskell)

CS 164 Handout 11. Midterm Examination. There are seven questions on the exam, each worth between 10 and 20 points.

A simple syntax-directed

Program Analysis ( 软件源代码分析技术 ) ZHENG LI ( 李征 )

Compilers - Chapter 2: An introduction to syntax analysis (and a complete toy compiler)

CS 4240: Compilers and Interpreters Project Phase 1: Scanner and Parser Due Date: October 4 th 2015 (11:59 pm) (via T-square)

Syntax Analysis/Parsing. Context-free grammars (CFG s) Context-free grammars vs. Regular Expressions. BNF description of PL/0 syntax

Types and Static Type Checking (Introducing Micro-Haskell)

Compilation 2013 Translation to IR

A Simple Syntax-Directed Translator

Chapter 3: Describing Syntax and Semantics. Introduction Formal methods of describing syntax (BNF)

Syntax and Grammars 1 / 21

EXAMINATION INSTRUCTIONS

Name EID. (calc (parse '{+ {with {x {+ 5 5}} {with {y {- x 3}} {+ y y} } } z } ) )

Itree Stmts and Exprs. Back-End Code Generation. Summary: IR -> Machine Code. Side-Effects

ASTs, Objective CAML, and Ocamlyacc

Syntax Analysis, III Comp 412

Decaf Language Reference Manual

CPS 506 Comparative Programming Languages. Syntax Specification

UNIVERSITY OF TORONTO Faculty of Arts and Science. Midterm Sample Solutions CSC324H1 Duration: 50 minutes Instructor(s): David Liu.

COP4020 Programming Languages. Syntax Prof. Robert van Engelen

CPSC 410? Advanced Software Engineering Mid-term Examination (Term I ) SOLUTION Instructor: Gail Murphy

Lecture 2: Big-Step Semantics

Principles of Programming Languages

First Midterm Exam CS164, Fall 2007 Oct 2, 2007

Parsing. Note by Baris Aktemur: Our slides are adapted from Cooper and Torczon s slides that they prepared for COMP 412 at Rice.

Compiler Construction

Fundamentals of Compilation

Question Points Score

Lexical and Syntax Analysis. Top-Down Parsing

Intermediate Code Generation

UNIVERSITY OF CALIFORNIA Department of Electrical Engineering and Computer Sciences Computer Science Division. P. N. Hilfinger

PART ONE Fundamentals of Compilation

Chapter 2 A Quick Tour

SMURF Language Reference Manual Serial MUsic Represented as Functions

CS251 Programming Languages Handout # 29 Prof. Lyn Turbak March 7, 2007 Wellesley College

Transcription:

CPSC 411, 2015W Term 2 Midterm Exam Date: February 25, 2016; Instructor: Ron Garcia This is a closed book exam; no notes; no calculators. Answer in the space provided. There are 8 questions on 14 pages, totaling 100 marks. You have 80 minutes to complete the exam. NAME: STUDENT NUMBER: SIGNATURE: The following are the rules governing formal examinations: 1. Each candidate must be prepared to produce, upon request, a UBCcard for identification; 2. Candidates are not permitted to ask questions of the invigilators, except in cases of supposed errors or ambiguities in examination questions; 3. No candidate shall be permitted to enter the examination room after the expiration of one-half hour from the scheduled starting time, or to leave during the first half hour of the examination; 4. Candidates suspected of any of the following, or similar, dishonest practices shall be immediately dismissed from the examination and shall be liable to disciplinary action; Having at the place of writing any books, papers or memoranda, calculators, computers, sound or image players/recorders/transmitters (including telephones), or other memory aid devices, other than those authorized by the examiners; Speaking or communicating with other candidates; Purposely exposing written papers to the view of other candidates or imaging devices. The plea of accident or forgetfulness shall not be received; 5. Candidates must not destroy or mutilate any examination material; must hand in all examination papers; and must not take any examination material from the examination room without permission of the invigilator; and 6. Candidates must follow any additional examination rules or directions communicated by the instructor or invigilator.

1 /15 2 /20 3 /4 4 /12 5 /14 6 /10 7 /10 8 /15 Total /100 2

Use this page for extra space if needed. 3

1. (15 marks) High Level Concepts So far you have implemented 5 compiler stages. The initial input is a program represented as ASCII text characters. The final output is Linearized Intermediate Representation (Linearized IR). In the space below, in order from first to last, write the name of each stage and briefly describe what it does. Stage 1 Name: Input: String of ASCII characters Output: Description: Stage 2 Name: Input: Output: Description: Stage 3 Name: Input: Output: Description: Stage 4 Name: Input: Output: Description: Stage 5 Name: Input: Output: Linearized Intermediate Representation (Linearized IR) Description: 4

2. (20 marks) Visitors In lectures and in the book, we discussed at least two options for implementing routines that operate on recursive tree data structures like abstract syntax trees, intermediate representation trees, and other similar representations in an object-oriented language like Java. In all cases, we represent trees by using a class hierarchy of tree elements. In the method-based approach, operations are implemented using methods, and the code for a routine is spread throughout the class hierarchy. In the visitor-based approach, the routine is encapsulated in a subclass of a Visitor class that is designed to interact with all of the tree elements. Consider the following code for a small language of arithmetic and boolean expressions. It implements a type checker for the language using the method-based approach. Your job is to reimplement from scratch the class hierarchy and type checker using the visitor-based approach. The abstract Visitor class and the Type enumeration have been provided for you. Method-Based Approach: public enum Type {INT, BOOL public abstract class Expr { public abstract Type typeo f ( ) ; public class Num extends Expr { public f i n a l i n t n ; Num( i n t n ) { this. n = n ; public Type typeo f ( ) { return Type. INT ; public class Plus extends Expr { public f i n a l Expr l h s ; public f i n a l Expr rhs ; Plus ( Expr lhs, Expr rhs ) { this. l h s = l h s ; this. rhs = rhs ; public Type t y p e o f ( ) { i f ( l h s. typeof ( ) == Type. INT && rhs. t y p e o f ( ) == Type. INT ) { return Type. INT ; else { throw new E r r o r ( Type E r r o r ) ; public class Equal extends Expr { public f i n a l Expr l h s ; public f i n a l Expr rhs ; Equal ( Expr lhs, Expr rhs ) { this. l h s = l h s ; this. rhs = rhs ; public Type t y p e o f ( ) { i f ( l h s. typeof ( ) == Type. INT && rhs. t y p e o f ( ) == Type. INT ) { return Type.BOOL; else { throw new E r r o r ( Type E r r o r ) ; 5

Visitor-Based Approach: public enum Type {INT, BOOL public abstract class V i s i t o r <R> { public abstract R v i s i t ( Plus e ) ; public abstract R v i s i t ( Equal e ) ; public abstract R v i s i t (Num e ) ; Solution: 6

Use this page for extra space if needed. 7

3. (4 marks) Dispatch Circle one answer for each of the following questions: The Visitor pattern uses O to determine which implementation of the visit method to call within the concrete visitor class. Dynamic Dispatch Overloading The Visitor pattern uses O among the expression classes. to determine which implementation of the accept method to call Dynamic Dispatch Overloading 8

4. (12 marks) Parsing Consider the following grammar for a super-simple expression language: Exp ::= Exp "+" Term Term Term ::= Term "*" Factor Factor Factor ::= Identifier Number "(" Exp ")" Identifier ::= "a" "b"... "z" Number ::= "0" "1"... "9" For simplicity, we ignore whitespace, and treat single characters as the tokens of our language. This grammar represents all strings of tokens that count as legal programs in our language. Unfortunately, this grammar cannot directly be used as the basis for a predictive, top-down, recursivedescent parser (i.e. an LL(1) parser). Briefly explain what the problem is with this grammar, explain how to fix it, and provide a new grammar that represents the same strings and is an acceptable LL(1) grammar. If needed, use /* empty */ to mark any empty productions in your grammar. Problem: 9

5. (14 marks) Translation to IR Using the IR syntax provided in the appendix, write out plausible IR code that a hypothetical translator might produce. You may assume that the code is from a valid program and that any variables in the code are allocated to a TEMP of the same name (e.g. x TEMP(x) ) 1. sum = sum + i; 2. i = i + 1; 3. i = j < 7? ( i + 1) : ( i + 2); (with a completely strict evaluation strategy that evaluates both branches) 4. i = j < 7? ( i + 1) : ( i + 2); (with a lazy evaluation strategy that only evaluates what it must) 10

6. (10 marks) Canonicalization We have seen a technique to transform Intermediate Representation (IR) terms into a more manageable canonical form, where all sequencing is at the top-level and all function calls contain only simple arguments. The algorithm conceptually implements a set of rewriting rules that, among other things, eliminate ESEQ nodes from an IR tree. The rewriting rules in the book are a subset of the rules necessary to eliminate all ESEQs from expressions. Provide rewrites for each of the following IR expressions to eliminate the ESEQ expressions. In some cases, you can improve the rewrite if you know that underlying terms can commute. If that s the case, provide rewrites for both the commuting and non-commuting case and say explicitly which terms must commute to justify the rewrite. 1. MOVE(TEMP t, ESEQ(s, e)) 2. EXP(CALL(e0, ESEQ(s, e1), e2)) 11

7. (10 marks) True and false For each of the following statements, indicate whether it is true or false. Explain your answer briefly. 7a. (2 marks) Every language that can be defined by a grammar (in BNF notation) can also be defined by a regular expression. 7b. (2 marks) In a statically typed language commands do not need to be type checked. 7c. (2 marks) The intermediate representation we are using (IR trees) would be strictly less expressive if it did not have the ESEQ primitive. 7d. (2 marks) Whether one or two passes over the parse tree is required to determine whether identifiers are being properly used is primarily determined by the compiler, and not by the language being compiled. 7e. (2 marks) In the majority of statically typed languages, the type of an expression is determined both by the type of its sub-expressions and the context in which it appears. 12

8. (15 marks) Liveness Analysis Consider the following list of X86-like instructions, extended with temporaries. To help us with register allocation, we would like to determine the liveness of variables along the control flow. Recall that X86 instructions have the source location as the first argument and the destination location (which may also be a source location depending on the instruction) as the second argument. Compute the liveness of temporaries (and registers) along this list of instructions. Between each instruction, write the temporaries that are live along that edge. 1: movq $1, t1 2: movq $46, t2 3: movq t1, t3 4: addq $7, t3 5: movq t3, t4 6: addq $4, t4 7: movq t3, t5 8: addq t2, t5 9: movq t5, %rax 10: subq t4, %rax 13

APPENDIX: IR Tree Syntax Items between /*..*/ are comments indicating the purpose of an element. They are not part of the actual syntax. E.g MOVE contains two sub expressions, the first one is the destination. Exp,* should be taken to mean a list of expressions separated by commas. Exp ::= CONST( int ) NAME( Label ) TEMP( Temp ) BINOP( Op, Exp, Exp) MEM(Exp) CALL( Exp /*fun*/, Exp,* /*args*/) ESEQ( Stm, Exp ) Stm ::= MOVE(Exp /*dst*/, Exp /*src*/) EXP(Exp) JUMP(Label) CJUMP(RelOp, Exp, Exp, Label /*thn*/, Label /*els*/) SEQ( Stm, Stm) LABEL( Label ) Op ::= PLUS, MINUS, MUL, DIV, AND, OR, LSHIFT,... RelOp ::= EQ, NE, LT, GT, LE, GE, ULT, ULE,... Label ::= <IDENTIFIER> TEMP ::= <IDENTIFIER> To make IR code more readable, it is acceptable to use SEQ(s1, s2, s3,..., sn) as shorthand for SEQ(s1, SEQ(s2, SEQ(s3,..., sn)))) Use meaningful formatting and indentation conventions to make the tree/nesting structure of the IR clear. For example: ESEQ( SEQ( MOVE(TEMP(x), CONST(0)), MOVE(TEMP(y), CALL(NAME(dothings), TEMP(y)) TEMP(x), CONST(5)))), 14