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:
- 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.
- 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.
- 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.
- 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 Jul 2024 11:27:42 EDT
by
Richard Chang
to Fall 2009 CMSC 431 Homepage