CS 352 Spring 2023
c++ | arm | assembly | java | Compiler代写 | 编译原理代写 – 本题是一个利用c++进行练习的代做, 对Compiler的流程进行训练解析, 是比较典型的c++/arm/assembly/Compiler等代写方向, 这个项目是Compiler代写的代写题目
Compiler project 3
1. Introduction to Code Generation Projects
We break code generation into two projects, Project 3 (P3 in short) and Project 4 (P4 in short), to give students sufficient time to get familiar with arm assembly programs. P4 will cover the entire MiniJavaP2 grammar, while P3 covers a small subset, called MiniJavaP3, for convenience. MiniJavaP3 is posted on Brightspace under Content/Projects/P3. This introduction applies to both P3 and P4.
P3 and P4 extend the parser built for P2 into a full compiler, by implementing a code generator that traverses the AST and converts it into an ARM assembly program.
The semantics of the input program follows the java standard. Students should carefully review relevant Java type rules and execution rules, with the authoritative document being the Java Language Specification (Java SE 7bEdition), abbreviated as JSE7 in the rest of this document. Chapters 4 and 15 are the most relevant parts.
The JSE7 document can be found at https://docs.oracle.com/javase/specs/jls/se7/html/index.html
The test cases will contain neither syntax nor type errors. However, correct memory allocation and code generation requires type information collected in P2, as explained in the lecture.
The compiler built in P3 and P4 is not expected to handle run time errors, as MiniJavaP2 has no throws clause. The test cases can be assumed to generate no run time errors. No run time type checking is expected, and neither is the handling of abrupt termination of expression, such as short-circuit evaluation of Boolean expressions
The criteria to determine the correctness of the generated assembly code is to run it and compare its output with that produced by any standard Java compilation/execution tool. We assemble and run the ARM assembly code generated by the compiler implemented by the students on a Raspberry Pi virtual machine image as mentioned in Lecture 20.
2. Main Tasks in Project 3
2. 1 Java Standard Classes and Methods in This Project
System.out.println and System.out.print are standard Java methods. It is expected that System.out.print is implemented by calling C standard function printf , with %d format for integers and %s for string literals. No additional white spaces are to be printed. System.out.println works in a similar way, with the only difference being the new line generated at the end. To simplify the handling of string literals, it is assumed that the input program contains no back slash character \.
2. 2 Language Features Implemented in P
To understand the exact set of language features, please refer to the MiniJavaP3 grammar mentioned in the introduction. This subsection summarizes the main features.
The input program does not contain either IF statements or loops. Neither does it contain logical operations (!, &&, ||) or comparison operators, (>, ==, and so on). As a result, the code generator in P need to consider only int and String variables.
All string variables will be declared as static members of the main class, e.g., private static String a = Hello; This allows easy access to the string literal, say Hello , that is placed in the .text section of the generated assembly code.
Declarations and invocations of methods are implemented in P3. The number of arguments for each method invocation will be limited to 4 or less in all test cases.
The code generator must handle command line arguments. All posted test cases import a single command line argument through the array parameter declared in the main() method header, as demonstrated in Lecture 22. The test case Java program immediately prints the first argument, and the ARM assembly program generated by the submitted Yacc program must also print the corresponding string. This print out will be checked when the code generator is graded. This is to prevent the code generator from generating an ARM assembly program that simply prints the result obtained from running a JVM.
No other variables in the input program are arrays. All variables are scalars. For simplicity, we do not have string concatenation operations in P3 either.
3. Expected Workflow
Students will write their lex/yacc scripts and C source files (if any) that are expected to be processed by Lex/YACC/GCC tools on data.cs.purdue.edu to produce an executable file, named codegen. Given a MiniJavaP 3 program, codegen should convert it to an equivalent ARM assembly program.
Next, the ARM assembly program produced by codegen will be copied to and tested on the Raspbian Pi VM image on the virtual machine vm2.cs.purdue.edu. (The use of the gcc assembler and the VM image has been presented in the lectures.)
The Linux scp command can be used to copy files between data.cs.purdue.edu and the VM image. We have found it easier to run the scp command from the VM image for both sending files to and receiving files from data.cs.purdue.edu.
4. Submission Instruction
It is mandatory for students to meet the submission instruction. Not following any of the requirements may result in grade deduction, up to a 10 point of penalty. (For example, if your code receives 90 points, the final score on the Brightspace for this assignment will be 80 points when maximum deduction is applied.)
Make sure that your submitted directory contains only the following files: the Makefile, your YACC and Lex programs, a README text file (explained below), and the .h and .c files (or the c++ equivalents) you have written to work with the Lex/YACC source code. This is to ensure that the system does not exceed the storage limit set by the system staff. Following good software engineering practice, implementation must not start until at least a high-level design is completed. The required README file is a design document for your code that must include the following two components:
a) Explain how you allocate memory for variables and how to assign offsets to variables and
compiler temporaries in the stack frame.
b) Explain (at a high level) how you generate the ARM assembly instructions as you traverse the
AST: Whether you generate the 3AC first or directly generate the ARM assembly instructions.
This document will be checked against your code when grading for consistency. Points may be
deducted if substantial deviations are found.
1 ) Use the following command on CS lab machines that run any Linux OS to submit your homework. No other forms of submission (e.g., email) will be accepted. No offline submission (such as email) is accepted.
turnin -c cs352 -p p 3 [name of the directory to be submitted]
Prior to executing the turnin command, it is mandatory for you to make sure your submitted directory meets the following content requirement.
- You are free to write your own Makefile, so long as the following requirements are met.
3 ) Your program MUST compile and run without any error on CS labs Linux machines. Please do a final test of this before submission, especially if you do your project on other computers.
The grader will run your Makefile by executing the command make codegen to produce the executable program named codegen. Hence, it is important that your Makefile produces such an executable when invoked.
You must also write your Makefile such that when make clean is run, your working directory will be cleaned, with the only remaining files being the README file, the Makefile, your YACC and Lex programs, and the .h and .c files (or the C++ equivalents) you have written to work with the Lex/YACC source code. This is to allow the grader to easily remove the files generated by the testing after your work is graded.
From previous experience, students may wish to run make clean first each time they run make to rebuild their code generator, just to make sure that the make tool does not mistakenly think your code generator is up to date and does not rebuild.
- Your codegen executable file will be tested for grading in the following steps:
Step 1: We run the following command on CS lab machines under Linux OS: > ./codegen program_name.java where program_name.java is the file name containing the input program. Your code must produce the ARM assembly code program_name.s. Note the file extension .s.
Step 2: program_name.s will be assembled and linked on the Raspberry Pi virtual machine image, using command gcc -o program_name program_name.s
Step 3: program_name is executed (with a single command argument, as mentioned in Section 2.2), and the print-outs are compared against the expected results for correctness.