Ch 7 Procedure Calling Sequences
16April 2008

We have seen how to set up the Activation Record (AR) of a procedure using one of two mechanisms: Displays (7.3.8) [with spim example] and Static (Access) and Dynamic (Control) Links (7.2.2). This handles the data local to a procedure, but not the items in the calling sequence.

links to SPIM code examples from spim sample Using Displays
Source code
SPIM code
caller code, callee start code, callee return code
Running the SPIM code

Figure 7.5 provides a General Activation Record 

	-------------------------
	| Actual parameters     |      often use registers for this, but show space to add to discussion
	-------------------------
	| Returned values       |      space for returned values of a function
	-------------------------
	| Control link          |      points to AR of caller
	-------------------------
	| Access link           |      may be needed to locate data needed by called proc (say in another proc's AR)
	-------------------------
	|  Saved machine status |      status of machine just before proc call
	-------------------------
	|  Local Data           |      variable names declared in proc
	-------------------------
	|  Temporaries          |      evaluation of expressions (not using registers)
	-------------------------
7.2.3 Calling Sequences
The calling sequences implement procedure calls by having code to allocate an activitation record on the RunTime stack and enter information into its fields. The return sequence is similar code to restore the state of the machine to continue executing from the calling procedure, after the call. These may vary greatly, depending on the language being compiled and the actual target machine and its operating system.

Code in a calling sequence is divided between the calling procedure ("the caller") and the procedure it calls (the "callee"). There is no exact division of run-time tasks between caller and callee, but the portion assigned to the callee is generated only once, while the "caller" may be at many locations and would need code generated each time. Therefore it is desirable to put as much of the calling sequence into the callee as possible. But the callee does not know enough to do it all.

Five principles for designing calling sequences and layout of activation records

  1. Values communicated between caller and callee are usually placed at the beginning of the callee's activation record, making them as close as possible to the caller's activiation record.
  2. Fixed-length items are generally laced inthe middle. In Fig 7.5, these are the control link, access link and the machine status link.
  3. Items whose size is not known early enough are placed at the end of the activation record. Most local variables have fixed length, can determined by the compiler by inspecting their type.
  4. Locate the top-of-stack point judiciously. Commom approach is to point to end of the fixed-length fields in AR. 






Fig 7.7 Division of tasks between caller and callee
Following the diagram in Fig 7.7, we have the calling sequences
  1. caller evaluated the actual parameters
  2. caller stores a return address and old value of top_sp into the callee's activation recrod. caller then increments top_sp to the position in Fig 7.7, past the caller's local data and temps and the callee's parameters and status fields
  3. callee savers the register values and other status information
  4. callee initialized its local data and begins execution

A corresponding return sequence is

  1. callee placed the return value next to the parameters
  2. callee restores top_sp using information in the machine-status field and then branches to the return address that the caller placed in the status field
  3. caller knows where the return value is, relative to the current, updated, top_sp; caller may use that value.

The scheme above allows the number of arguments of the called procedure to vary from call to call, which is needed in a construct such as the C language printf function.

Return to RunTime Environments