






Study with the several resources on Docsity
Earn points by helping other students or get them with a premium plan
Prepare for your exams
Study with the several resources on Docsity
Earn points to download
Earn points by helping other students or get them with a premium plan
Two parts of a midterm exam for the cs164 decaf programming course. The first part focuses on dataflow analysis to optimize decaf programs by identifying and eliminating redundant null checks. The second part deals with extending decaf with java-style interfaces, including the design of dispatch tables for interface calls. Students are expected to develop solutions for both parts, making assumptions as stated in the document.
Typology: Exams
1 / 10
This page cannot be seen from the preview
Don't miss anything!







Fall 2004
This question asks you to develop a simple dataflow analysis that can be used to optimize Decaf programs be removing from them unnecessary null checks. Background. Because dereferencing a null pointer crashes the program, in Decaf, a run-time check ensures that a null pointer is never dereferenced. This check takes place just before the pointer is dereferenced using the "." operator. For example, the statement "p.f(); " might be translated by the compiler to if (p == null) print_error_and_exit{); p.f 0 ; The null checks can be costly, but luckily we can optimize some of them away. Specifically, a check can be safely removed if the compiler can guarantee that the pointer being dereferenced will not be null for any program input. The problem. In this problem, you will develop a dataflow analysis to identify such redundant checks, so that they can be eliminated by the compiler. In particular, for every pointer dereference, you want to know whether the variable being dereferenced may be null; if it may not, then you can eliminate the null check. Simplifications. In order to simplify the analysis, you can make the following assumptions:
X = new B(); (B)
x = y; (B)
x = y.moo(); (B) (hint: If y were null, you would never reach point (B))
Interface references. To make use of interfaces, Java introduces interface reference variables, which are like object reference variables, except that an interface variable of type I is allowed to point to objects of any type T such that the class T implements the interface I. For example, the interface reference variable t of type IM (introduced above) is allowed to point to an object of type A or C but not of type B, even though B happens to contain a method m(): IM t; t = new A(); // LEGAL t = new B(); // ILLEGAL (even though B contains method m) t = new C(); // LEGAL t.m(); // LEGAL t.k(); // ILLEGAL (even though t is guaranteed to point // to an object with method k) Compiling interfaces. Compiling Java interfaces boils down to supporting a new kind of method call t.m(), named interface method call. To the programmer, this call behaves like the virtual method call used to invoke instance methods, except that the object on which you invoke the method m comes from an interface reference variable t, as opposed to from an object reference variable. Example (continued). The code below makes both kinds of calls. B b; // b can point to any object of type B or subclass of B IK ik; // ik can point to any object that implements interface IK if (x==l) { b = new B(); ik = new A(); } else { b = new C(); ik = new C(); } b.k(); // virtual call ik.k(); // interface call When x==1, the program outputs B:k A:k Turn over.
The questions.
Questions on this page will take you some time.