12 Assignment 5: The CPSC411 Compiler Recovery and Reinvestment Assignment of 2020.
12.1 Assignment Summary
The goal of this assignment is to (1) give you a chance to recover from technical debt (2) give you time to review the lessons of the past four assignments prior to the midterm.
Due Friday, Feb. 28, 2020. There are no extensions on this assignment; the late policy does not apply.
You have addressed the issue in your code. (Fixing bugs, adding tests, redesigning code...)
You submit a short written document explaining what the problem was and explaining the fix. If the exercise you lost points on required making a design decision, you should also explain the design decision or the change in the design decision.
(Possibly), you can explain the code in a code walk.
We will ask some subset of students, alone without the rest of their group, to
do a code walk with a TA to ensure you can explain all of your code.
We will not ask everyone, but we may ask anyone.
Per the syllabus, you should be able to explain all of the code base, not only
"your part"—
To receive points back, you must follow the instructions above and below. There will be no exceptions.
To assist with understanding the prior assignments, starting on Wednesday Feb. 19th, we’ll provide access to the entire A4 compiler so you can run examples and tests at: https://www.students.cs.ubc.ca/~cs-411/2019w2/a5-interrogator.cgi
12.2 Fixing Your Code
You should correct the code in the original repository and push to the master branch on the repository. For example, to fix the individual assignment a1, you should fix the code in your a1 project repository. To fix the code for a4, you should fix the code in your a4 project repository.
For the individual assignments, a0–a2, you may discuss the fixes with your team, and reference code you have written together. For the team assignments, a3 and a4, you should worth togther to with your team to fix that code.
You cannot fix text questions, such as Exercise 6 on a3. These were already asking you to think and we were generous with the grading.
You are not required to fix every exercise; we will skip any code that has not changed and any exercise not included in the report.
12.3 Submitting Your Report
In addition to fixing the code, you must write a short written report for each assignment that you want regraded. If you want to have a1, a2, and a3 regraded, you must write a report for each.
The report must be in a Markdown file, readable in plaintext, named <assignment-number>-regrade-report.md, in the top-level directory of the repository to be regraded. If you want a1 regraded, there should be a file a1-regrade-report.md in the top-level directory, next to a1.rkt, in the master branch. If you want a2 regraded, there should be a file a2-regrade-report.md in the top-level directory, next to a2.rkt, in the master branch. Etc.
The file should clearly and concisely describe what fixes you have applied to your code. You should label each exercise with a markdown section heading. There should be only one heading per exercise.
For example, below is an example of a report for a1 in which I made several mistakes: I was missing important tests for check-paren-x64, made a mistake in the design of check-paren-x64, and neglected an important design decision.
* Exercise 1
- Added missing test for checking a program containing the instruction `(set!
reg int64)`.
- Added missing test for checking the empty program `(begin)`.
- Added missing signature and purpose statement.
Fixed the case for when `check-paren-x64` is checking an empty program; the
specification allows for an empty program, but the implementation incorrectly
assumed at least one instruction.
* Exercise 2
Changed the purpose statement to indicate that using uninitialized registers
is undefined behavior, and added test that raises some kind of internal error.
Making this undefined behavior allows the compiler to emit fewer instructions
and thus faster code, but means the behavior of uninitialized registers is
unpredictable and depends on the underlying machine.
For simple mistakes, like missing tests, your report can simply enumerate the fix. For non-trivial mistakes, your report should indicate that you understand the problem and the fix.
For individual assignments, you should write this individually. For team assignments, you should work as a team.
12.4 Code Walks
We will ask some subset of students to walk through their corrected code with a TA. Students will do this alone, without their team, regardless of whether the assignment was an individual assignment or a team assignment. You should be able to explain most of the code and all design decisions.
12.5 Marking
We will return up to half of the points lost on each exercise if:
Your fix is correct.
Your report explains the problem and the fix completely and concisely.
If asked to do a code walk, you can explain the problem and the fix.
We will not return any points on exercises that asked for a written answer. You should review these anyway, since the midterm will include these kind of high-level questions.