Class 37: Translating Procedure Calls

Held: Thursday, 29 April 2004

Summary: Today we conclude our discussion of translation by considering the translation of function and procedure calls.

Related Pages:

• EBoard (morning).
• EBoard (afternoon).

Notes:

• Today's class will be held during lab time on Thursday.
• I've heard some complaints about your group selection for the final phase of the project. Live with it.
• Time for questions ...<

Overview:

• Format of stack frames.
• Allocating space for locals and parameters.
• Division of responsibilities.
• Function/procedure initialization.
• Function/procedure cleanup.
• Caller responsibilities.

Translating Procedure Calls

• We've come full circle in our discussion of translation.
  • We started by thinking about stack frames as a mechanism for holding parameters and local variables.
  • We now return to stack frames from the perspective of the code needed to build and use them.
• We need to ask ourselves whether we want to mimic the format used in gpc or whether we want to design our own.
• In doing so, we need to think about whether caller or callee takes responsibility for different aspects of the maintenance.
  • Remembering and updating old frame pointer.
  • Remembering and updating old stack pointer.
• You'll note that there are many tradeoffs in these decisions
  • We can have caller push parameters and callee push room for local variables, but that seems to be two sets of pushes. However, if the caller pushes all the necessary space, it needs to know how much the callee needs.

Translating Declarations

• Our translation of procedure calls depends first upon the translation of procedure declarations.
• That, in turn, depends on our design for stack frames (and for the stack).
• I may update PAL so that there are extend push and pop operations, which will allow you to ignore the direction in which the stack grows.