Prerequisites/Relaxations
Your compiler needs to be able to handle the first three stages (up to and including generic functions, but no classes) for this assignment. We will not test higher-level language features.Deliverables
Your submission has to have two parts:
- An executable jar file containing the Cubex-to-assembly compiler and its sourcecode.
- A text file as described below.
It is very important that you include the source code of your compiler this time. It may be needed for grading.
The Compiler
As in the previous assignments, this program should take a file name as an argument, read that file, check it and print results to the standard output/a result file as explained below. The possible results are:- If the input has a lexing, parsing or typing error, the program should print "reject"
- Else, the program should output an x64 assembly code in a file format to be determined
What Code Do I Generate?
The semantics of the code you generate stay the same as in PA4 and PA5,
except that you cannot submit a preamble C code file but need to print all the respective assembly code into one file.
Your code needs to observe System V Calling Conventions for interaction with our provided C files from the previous assignment such that the compiled files can be linked together. In the provided files you will find the cubex_external_functions.o and master.o. The assembly that you output must link against these files! The c code from which they were generated is also provided, for your convenience. This version of the cubex library differs in two significant ways from that for PA4 and PA5.
(1) To run compiled code, you should now use the command ./a.out in.txt out.txt 0 where in.txt is to be read line-by-line by read_line and out.txt is the destination for output given to print_line. The trailing 0 is an artifact of our grading infrastructure; do not worry about it.
(2) All functions now operate on 64-bit words. This is to ease your pain in dealing with data types of different sizes. For our purposes, a character is a 64-bit word all of whose bytes except one are ignored, and similarly for an int. We have compiled a list of resources on assembly code generation:
- Intel Architecture Software Developer's Manual
- Intel Architecture Optimization Manual
- Gentle Introduction to x86-64 Assembly
- x86-64 Machine-Level Programming
- System V Calling Conventions
Staging
Your code needs to be able to handle stage 3 of the previous assignments. We may put more weight on easier tests, but we make no guarantees on the extent of that.
How to submit
You have to include the complete source code in the jar-file, including inputs for any lexer/parser generators you might use. You will need a manifest file (MANIFEST.MF) that sets the classpath. Your manifest file should look like this:
Class-Path: . antlr-4.1-complete.jar
Main-Class: [your-class-name-here]
The following code snippet does this packaging for you (.g4 is the file extension for ANTLR files).
jar cvfm x3c.jar MANIFEST.MF *.class *.java *.g4The text file
Finally, we ask that you submit a small text file (.txt) that contains the following information:
- Who you discussed the problem set with. Remember that the solution must be your own, but you can discuss your ideas with others provided you mention that in this file.
- What the distribution of work in your team was like. Who did what?
- Any additional comments you might have about the problem set.
Source control
We recommend that you use some kind of source control. Be aware that your repositories should not be publicly viewable on the web. GitHub offers private repositories for students.
Testing
You should thoroughly test your solutions before turning them in. We will try to automatically test your submissions to a large extent. By now, you should now how to make your submissions testable. Share test cases with your fellow students, and ask on Piazza if parts of the semantics of your extension are not clear to you.