CS 352 Spring 2023 Compiler Project 5
Hello, dear friend, you can consult us at any time if you have any questions, add WeChat: daixieit
CS 352 Spring 2023
Compiler Project 5
Due May 3rd, 2023, 11:59pm
1. Project Description
Project 5 improves the code generator in Project 4 by implementing the liveness analysis and register allocation scheme presented in the lectures, such that the ARM assembly code generated from the input MiniJavaP2 program can efficiently uses the hardware registers, reducing memory references as the result.
The scope of the language covered by this project is identical to that covered by Project 4, except the following simplifications:
• No array references will appear in the test cases unless they refer to the array argument of the main method that imports the command line arguments.
• The interference graph is always colorable with the %a registers (i.e., the argument registers) and the %v registers (i.e., the variable registers) available on the ARM processor architecture implemented by the Raspberry VM for the project.
• REMINDER: Instructions for saving and restoring callee-save registers are still needed. Otherwise, the resulting code may not execute correctly
All test cases are assumed to be syntactically correct without type violations. It is also assumed that the test cases will not cause run-time exceptions. Hence no errors are to be reported.
The grading of each test case has two components, namely correctness and performance, as explained below.
1.1 The Correctness Component (30%)
If the program output is incorrect, then no points will be earned for the specific test case. If the output is correct, then 30% of the total point assigned to this test case is granted for correctness.
1.2 The Performance Component (70%)
Up to 70% of the total point is due to the performance of the code generated for the specific test case. The performance is measured by counting the total number of load/store instructions issued by the generated code when executed under the input used for the testing, compared against a conservatively estimated achievable performance.
We will post a Python script that can be invoked in a GDB running environment. This script records the trace of instructions executed for the assembled code. The grading script will recognize and count the memory load/store instructions in the trace. We will post the part of the script that recognizes and counts such instructions, so that the students can run it and get an idea how well their register allocation scheme performs.
For each test case, we have conservatively estimated an achievable lower bound on the number of load and stores executed at run time. If the machine code generated by the submitted code generator approaches that lower bound with a certain percentage of difference, say x%, then the full mark is earned for that test case. Such a percentage is to be determined based on the overall performance of the class. If the number of load and stores achieved is above the estimated lower bound by more than x%, points will be deducted according to the level of performance degradation. If the number of load and stores is almost as high as no optimized register allocation at all, no performance points are earned.
2. Submission instruction
Submission of this project must follow the exact instruction given in Project 4, except the command for submission will be:
turnin –c cs352 – p P5 [your working directory]
NOTE: Deviation from the submission requirement will get up to 10 points of penalty. (For example, if your code receives 90 points, the final score on the Blackboard for this assignment will be 80 points, assuming the maximum penalty of 10 points.)
2023-04-25