MIPS RISC Conventions: Expectations for Program 4

Purpose

The purpose of this document is to clarify exactly which MIPS RISC procedure/register usage conventions you are expected to follow to get the most credit for Program 4.

We have not presented all the MIPS RISC conventions for procedure linkage and register usage exactly as they are stated in the MIPS RISC Architecture manual. And, some of what follows are not MIPS RISC conventions at all, merely clarifications of our expectations. The things that we do expect implemented in Program 3 are as follows.

Conventions to Follow

  1. Correct usage of registers. All $s registers must be preserved across procedure calls. That is, if procedure A calls procedure B, then A can safely assume that the $s registers will contain the same values upon the return from B.

    $t registers do not need to be preserved across procedure calls; however, if they contain live values, they should be saved before making a call. That is, procedure A should save any $t registers containing live values before calling procedure B, because procedure B is free to overwrite any $t register. (Note: a register contains a "live value" if it could be read before being written).

  2. Parameter location. The first four parameters to any procedure are passed in registers $a0-$a3. The first parameter always goes in $a0. If there are more than 4 parameters to a procedure, the first four still go in registers $a0-$a3, and the remaining ones go on the stack.
  3. Space within activation record for parameters. The MIPS RISC conventions state that a procedure must allocate space in its activation record for all out-going parameters. Because the activation record is allocated/deallocated at the beginning/end of the procedure, it must contain space for the maximum number of outgoing parameters. For example, if a procedure calls one procedure with 2 parameters, calls another procedure with 1 parameter, and calls yet a third procedure with 7 parameters, it must allocate space for 7 parameters in the activation record. This space is reused for each set of parameters. Some of this parameter space may be unused for some calls, but it must be allocated. Allocate a minimum of 4 words.
  4. Frame pointer. You do not need to use a frame pointer. If you wish to use a frame pointer, dedicate an $s register to be the frame pointer. Because the activation record size does not change in the body of the procedure, it is possible to access anything in the activation record, as well as the parameters passed to a procedure using the stack pointer.
  5. Size of activation record. There are two choices for the size of a procedure's activation record. A compiler would either allocate an activation record that is the same size for ALL procedures (and it would contain extra, unused space for many procedures), or it would allocate an activation record that is exactly the correct size for a procedure. This size would be different for different procedures. You may implement either of these choices, but be consistant within your program.
  6. About leaf procedures. A leaf procedure is one that contains no calls to other procedures. There would be no jal instruction within a leaf procedure. You are not required to allocate or use an activation record for leaf procedures, unless you need space for local variables or to save $s registers. Therefore, you do not need to save the return address (on the stack) for a leaf procedure. Notes: