CS712/CS812
Possible Phase 2 Assignments
Spring 2001


You will be assigned one of the following tasks. Please let me know by Monday March 5 any preference you might have. I will give you a definite assignment no later than Wednesday March 7. This phase ends on Sunday April 1.

  1. Compile local declarations and struct/union declarations. Utilize the "officially sanctioned" code developed for global declarations during Phase 1.

    You should handle pointer and array declarators. You may limit the syntax so that array dimensions must always be given. You may assume the dimension given will always be an unsigned integer constant. You do not need to handle function declarators or abstract declarators. You do not need to handle typedef, but you should handle all other storage class specifiers. You do not need to handle enum types or typedef names, but you should handle all other type specifiers (including struct/union types). You should handle type qualifiers. You should support multiple declarators per declaration. You do not need to handle initializers. You do not need to handle bit fields.

    Local variables should be assigned an offset into the "locals" area of the stack frame. This offset should be stored into the ST_DR for the variable. The total amount of stack space used by a function's local variables should be computed and left in a global variable so that code can be properly generated for function entry (frame allocation) and function exit (frame deallocation). (Code generation for function entry/exit is not part of this assignment however.)

    Write a function that, given a struct/union TYPE and a ST_ID for a member of the struct/union, will return the offset of the member in an object of the struct/union type. (If the ST_ID is not found on the given type's member list, return -1.) This function will be Alpha-specific.

    Be sure to carefully consider what semantic errors need to be detected and reported in the processing of local variables and struct/union declarations.

  2. Compile function definitions, function declarations, function calls and variable references. Utilize the "officially sanctioned" code developed for global declarations during Phase 1.

    You should support fully prototyped functions. You do not need to handle a variable number of parameters. You do not need to handle "old-style" functions. Parameter and return types may be limited to those processed during Phase 1, plus types that use function declarators. You also should be able to handle the use of "void" to mean there are no parameters.

    When processing a function definition, you should complete the following subtasks:

    1. Initialize a global variable to serve as a running count for determining local variable offsets.
    2. Initialize a global variable to contain the function name.
    3. Determine the TYPE of the function and install the function and its parameters in the symbol table.
    4. Generate code for function entry.
    5. Call the semantic-analysis routine ("analyze") for the function body.
    6. Call the code-generation routine ("encode") for the function body.
    7. Generate code for function exit.

    You should add code to the "analyze" and "encode" functions to handle function calls. This will include handling argument conversion, determining the return type and generating code to pass arguments, invoke the function and process the return value.

    You should add code to the "analyze" and "encode" functions to handle variable references. This includes looking up the identifier in the symbol table to confirm that it is a variable and to obtain its type. (We will treat functions like variables, representing them with a variable tree node. Note that we are requiring that functions be fully prototyped with a definition of the function visible at a call site for the function.) If the type of the variable is "deref-able", then place a deref tree node on top of the variable tree node. Generate code for both the variable node and the deref node. Variable types may be limited to those processed during Phase 1, plus types that use function declarators. You should be able to handle both global and local variables.

  3. Add support for the following operators: +, -, /, *, ++, --, unary -, % and =. You are only responsible for handling arithmetic types (except the enum types) with these operators. Utilize the "officially sanctioned" code developed for constructing expression trees during Phase 1. Also use the code developed in Phase 1 (task 6) for performing the "integral promotions" and the "usual arithmetic conversions".

    You should add support to both the semantic-analysis routine ("analyze") and the code-generation routine ("encode").

    Be sure to consider semantic errors. When errors are encountered, use the "error TYPE" to denote the existence of the error in the abstract-syntax tree and key on the "error TYPE" to avoid a cascade of errors. This is in addition to issuing an appropriate error message through the message module, of course.

  4. Add support for the following operators: !, <, >, <=, >=, ==, !=, &&, || and =. You are only responsible for handling arithmetic types (except the enum types) with these operators. Utilize the "officially sanctioned" code developed for constructing expression trees during Phase 1. Also use the code developed in Phase 1 (task 6) for performing the "integral promotions" and the "usual arithmetic conversions".

    You should add support to both the semantic-analysis routine ("analyze") and the code-generation routine ("encode").

    Be sure to consider semantic errors. When errors are encountered, use the "error TYPE" to denote the existence of the error in the abstract-syntax tree and key on the "error TYPE" to avoid a cascade of errors. This is in addition to issuing an appropriate error message through the message module, of course.

  5. Add support for the following statements: if, for, while, break, continue and return. Utilize the "officially sanctioned" code developed for abstract-syntax trees during Phase 1.

    You should add support to both the semantic-analysis routine ("analyze") and the code-generation routine ("encode").

    Be sure to consider semantic errors.

Code produced by the class during Phase 1 will be available in ~cs712/public/phase1. I will place code there as soon as I have had a chance to evaluate the Phase 1 submissions.


Last modified on February 28, 2001.

Comments and questions should be directed to pjh@cs.unh.edu