UMBC CMSC431, Compiler Design Principles, Fall 2009


Project 6

Due: Monday, November 23, 2009, 12:00pm (noon)


Objective

In this project students will add function calls to their programming language. This latest version must also do type checking on the actual parameters in function calls and procedure calls.


Assignment

Add the following features to your programming language:

  1. Extend procedures in your programming language to allow a return value (i.e., now they are functions). The type of the return value can be boolean, integer or floating point. Your programming language must allow the value returned by a function to be used within an expression (boolean, integer or floating point) including expressions that are actual parameters in another function call.

  2. Extend return statements to include a return value. Your programming language should allow multiple return statements and allow return statements to appear anywhere in the body of a function/procedure.

  3. Type checking: your compiler should check that the number of actual parameters in a function/procedure call is the same as the number of formal parameters in the function/procedure definition. The types of the corresponding parameters must also match. In case of error, your compiler should print out a "helpful" message. Your compiler should also check the type of the value returned by a return statement.

  4. Make the functions and procedures global using the NASM "GLOBAL" directive. This tells the linker to allow programs written in C to call functions written in your programming language. (Yes, there will be test cases that use this feature.)


Implementation Notes

As in Project 5, your parameter passing scheme must follow the C Function Call Convention (see description). The code for procedures and functions you compile must be compatible and interoperable with the code generated by GNU's gcc.

In this function call convention, return values that fit in 4 bytes are returned in the EAX register. For values longer than 4 bytes, the function is called with an "extra" first parameter. This extra parameter holds the address where the return value should be stored. (This address usually points to a location in the callee's stack frame.)

However, floating point return values use a different scheme . These are returned in the top of the FPU's register stack. (This is the case even for 4-byte floating point values.) The advantage is that the returned value can be immediately used in floating-point calculations. In our stack-based scheme, however, the floating-point return value should be moved immediately to the regular CPU stack.

This brings up another point: when you call a function, the FPU stack should be "clean". This is to make sure that the callee has all 8 FPU registers available. Similarly, when the callee returns, the callee should leave the FPU stack clean (with the possible exception of a floating point return value stored in one register).


Testing

TBA. Test programs written in C will be distributed.

Translate the following C programs into your programming language. (Note: the first 10 of these programs are just short programs to see if your compiler is doing type checking for function calls and return statements correctly. They should result in syntax errors.) You should compile and run the C program and check if it produces the same answers as code generated by your compiler.

Note: the assumption is that your compiler handled the test programs from Project 5 correctly. Thus, none of these test programs check that local variables are handled correctly. If your Project 5 did not handle local variables, please make sure that you submit the test programs from Project 5 as well.


Submitting Your Project

We will continue to use the repository for Project 5. Please make sure you use "cvs add" to include new files before issuing a "cvs commit" command.

Please include a README file that describes the status of the submitted project (e.g., whether all the features implemented). Instructions for compiling the project should also be included here. The README file is also a good place to describe any oddities, traps and pitfalls involved in using your compiler.


Last Modified: 22 Nov 2009 00:10:17 EST by Richard Chang
to Fall 2009 CMSC 431 Homepage