due: Friday, November 1
In this assignment you will implement code generation for the Cubex programming language.
Your submission has to have two parts:
cubex_lib.h that you can
#include in your generated C file.
out.c (details below)
We've decided not to burden you with reading a full semantics for the Cubex language. That means that you should implement the "obvious" semantics of statements, expressions, classes, interfaces, et cetera. (We place "obvious" in quotations because the correct mathematical formulation of those semantics is far from obvious!)
The nitty-gritty details:
We provided a small library and makefile that you have to use for your compiler.
The top-level execution of the compiled Cubex program should be triggered by a call to the function
cubex_main() is forward-declared in
cubex_main.h). The file
out.c should #include exactly three other files:
cubex_lib.h and be otherwise self-contained.
The only code allowed to run when a Cubex program is invoked is that in
out.c and that in our provided library functions. A compiler breaking this rule intentionally
will get a 0.
Your output must adhere to the ANSI C90 standard and generate no warnings when run with -Wall.
Our provided header file will define the following functions:
void print_line(char* str, int len)
len characters starting at
. Note that this
means you should be using some String data structure that stores lengths, not
regular old null-terminated C strings!
int next_line_length() which gets the length of the next input line. Returns 0 if
there are no more lines of input. (All input Strings will be guaranteed to be nonempty.)
void read_line(char* buffer) which writes the next input line to the
buffer starting at
buffer, or is a no-op if the input is empty.
void* x3malloc(int size)
void x3free(void* ptr)
char unichar(int uni) which returns an ASCII character given its unicode representation.
(We will not test any characters out of ASCII range.)
int charuni(char c) which is the inverse of
A few parts of the semantics are less than obvious. The following constraints, along with the above directive to implement the obvious semantics whenever such are available, should give you enough information to complete this assignment. Of course, we reserve the right to add to this list when we discover that we have (inevitably) left something out.
The initial variable input of type
retrieved by successive calls to
read_line. Also, read_line should only be called when a line of input is actually needed.
For example, the generated program for:
should print "Hello" and "World!" before calling read_line.
Iterable<String> returned at top-level should
be printed with
String should not terminate if passed an infinite
This assignment will be graded in a staged mode, which means that you can concentrate on some parts of the assignment and leave others out with a predictable loss of points. Our tests will be organized in the following stages (same as PA3), meaning that programs only consist of the things in that stage and the preceding ones:
Note: Any stage (including stage 1) may contain code related to Iterable
The distribution of tests to stages is identical to PA3:
80% of the tests will test programs in stages 1-3.
10% of the tests will test programs in stages 4 and 5.
10% of the tests will test programs in stages 6-9.
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:
The following code snippet does this packaging for you (.g4 is the file extension for ANTLR files).
Like the generated code, this file may only
#include the library files we provided.
You can use it to implement all data structures and functions common to all generated programs.
Finally, we ask that you submit a small text file (.txt) that contains the following information:
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.
You should thoroughly test your solutions before turning them in. We provided some basic test examples for you to play with, but keep in mind that we will test your submissions with more complex examples, too. The way a test works is that after running
the content of x3_test1_actual.out should be equal to x3_test1.out .