Process C function definitions and C expression statements.
To receive 70% of the credit: You must be able to handle function definitions. This includes determining the function return type (you are only responsible for handling functions that return 'int', 'char', 'float', and 'double'), installing the function in the symbol table, generating the necessary assembly code to enter and exit the function, and generating the assembly code for the function body (the statements inside the function). At this level you only need to handle void parameter lists, and you do not need to handle local variable declarations.
For this assignment the only legal statement inside a function is an 'expression statement'. For the 75% level of this assignment, expression statements can only be made up of: the assignment operator (=), the basic arithmetic binary operators (+,-,*,/), the unary minus arithmetic operator (-), unsigned integer constants, unsigned double-precision floating-point constants, the basic comparison operators (==,<,>), global variables (only types 'int', 'char', 'float', or 'double'), parentheses, and function calls to functions that return ints and take no parameters.
You are responsible for doing the appropriate ANSI 1989 C type checking of these expression statements and determining the necessary type conversions. Be sure you understand the ANSI 1989 C type conversion rules.
Assume that a function call involving an undeclared function name (it is presumably in another file, or appears later in the current file) will return a value of type 'int' and has a void parameter list. Also assume that a function definition without a return type specification declares a function that returns 'int'.
You are also responsible for doing the appropriate semantic error checking. For example, the use of an undeclared identifier in an expression is illegal (other than an undeclared function name, discussed above).
You need not issue an error message for an expression statement
that has no side effects.
That is, this statement may be processed without a message:
x+6;
Since we are not yet implementing the 'return' statement, you do not need to check that the proper type is being returned by a function being defined.
To receive 85% of the credit: In addition to obtaining the 70% level, you must add parameter declarations in function definitions, parameter references in expressions, and function calls that include parameter lists. You only need to handle parameters of type 'int', 'char', 'float', and 'double'. You also need to add function declarations, if you did not previously implement these in Phase 1.
To receive 100% of the credit: In addition to obtaining the 85% level, you must fully implement compound statements. Implementing compound statements means you must support local variable declarations and local variable references within expression statements. Since compound statements can be nested this means you must implement C's block structured scope rules. You only need to handle local variable declarations of type 'int', 'char', 'float', and 'double'.
At all levels you are responsible for detecting the relevant duplicate declarations.
The appropriate Intel IA-32 assembly code to be emitted for this assignment will be discussed in class.
Your compiler should be capable of detecting multiple semantic errors in one file. You can make arbitrary decisions about how to proceed when errors occur. The important point is to do something so you can proceed (without causing a later 'bus error', 'segmentation fault', etc.).
All semantic error messages should include an estimate of the line number where the error occurred. Support this requirement by adding the current line number (available from the scanner) to each AST node that you build. Because of the vagaries of how the parsing algorithm works, the line number available to you in the scanner is only estimate and may be slightly wrong at times. It is good enough for our purposes.
You may allow the compiler to stop processing with the first syntax error. A syntax error is defined with respect to the C grammar distributed for Phase 1.
In ~cs712/public/phase2 are the public test files. Remember there will be hidden test files as well, so do your own testing too.
You will need the 70% level functionality in order to do later parts of the project. So be sure you at least get that much of the assignment completed.
Remember: you get credit for features successfully implemented. You do not get credit for attempting to do something; you get credit for the things that you can successfully demonstrate work.
Finally: you should adequately document and structure your program.
You must turn in all source files (including the scanner and parser) and the Makefile for your compiler. Please place all your files into a tar file called src.tar that un-tars into a directory called src. The default goal of the Makefile should be to build the compiler executable called scc in the src directory.
To turn in this assignment, type:
~cs712/bin/submit phase2 src.tar
Submissions can be checked by typing (also on agate.cs.unh.edu):
~cs712/bin/scheck phase2
Note: You must approach this assignment by first completing the 70% level, then the 85% level, and finally the 100% level. First, I believe this will most likely lead to the greatest success for the most of you. You need to get a piece of the assignment working and then add to it as much as you can until you run out of time (or energy). (Do not try to sit down and do the whole assignment at once!) Second, this is how I will grade it. For example, my tests for the 85% level will assume you have the 70% level done.
The assignment is due on Sunday March 4. There is a grace period to 8am on Monday March 5 when no late penalty will be assigned. Submissions between 8am February 13 and 8am March 6 will have a late penalty of 15 points. Submissions between 8am February 14 and 8am March 7 will have a late penalty of 30 points. No program may be turned in after 8am on Wednesday March 7.
Remember: you are expected to do your own work on this assignment.
Comments and questions should be directed to hatcher@unh.edu