CS255 Syllabus

Manipulating the register window: the `save` and `restore` instruction of SPARC

Moving the register window forward and backward
- The "save" and "restore" instructions manipulate the register windows.
- The save instruction will move the SPARC register window forward
- The restore instruction will move the SPARC register window backward
- The "save" and "restore" instructions in SPARC have no equivalent in M68000, because M68000 was not designed with register windows.

Purpose of "overlapping" register windows

Recall that:

The purpose of SPARC's overlapping register windows is to pass parameters and the return value between the calling function and the called function
Using the overlapping register windows, the parameters and returned value can be passed without using the system stack that is located in memory that is very slow compare to registers

Example:

Note:

The main() function passes parameters param0 and param1 using output registers o0 and o1 to the function func()
The function func() can slide the register window forward
After the slide, the parameters param0 and param1 will in registers that are named i0 and i1 (input registers)

By sliding the register window forward, the function func() also "creates":

its own private set of local registers
a new set of output registers that func() can use to pass parameters to functions that func() will be invoking in the future

Sliding the register window forward: consequences...

The save instruction is used to slide the register window forward
Effect of the save instruction:
Example:

Problem:

There are only 128 window registers available in SPARC
Each save instruction will expose 16 new registers
After 6 save operations the register window will slide to the position given in this figure:
We need 16 new register to slide the register window further.
We only have 8 unused registers !!!

In other words:
This phenomenon is called register window overflow...

$64,000 question:

Creating the illusion of have (almost) infinitely number of windows of registers

SPARC creates the illusion of having a huge number of register windows by "wrapping the registers around"

Graphically:

Notes:

When CWP = 0 (000 binary), the output registers are wrapped around
When we decrement CWP again, (CWP is a 3-bit field inside the PSR), the value of the CWP becomes 111 (binary)
We are now using the same window as the beginning of the program !!!

Problem with the "wrapped around" registers...

There is a problem with this method:

The wrapped around registers contains important values used by a previously invoked function
We must save the values in the wrapped around registers (and restore them back when the execution returns to the function that needs the value)

Example:

Initially, function func1(..) received a parameter value in reg. i0:
After 6 "save" instructions, the window has slide to:
When func2() invokes func3() and func3() slides the window further, we will have:
Now, if func3() pass a parameter value 314 to another function, it will overwrite the parameter of func1():

Fixing the "wrapped around" register problem

Idea:

$64,000 question:

Where in memory should we save the values ???

Answer:

It must be on the system stack !
Because the values being saved are parameter variables and local variables
These kinds of variables are Last-In-First-Out (stack) !!!

Solution:

When a function slides the register window forward, it must also allocate space on the system stack to save its own register window !!!!

Example:

Before sliding the register window forward:
After sliding the register window forward:

Note:

Allocating (reserving) memory on the stack is not "automatic"
The save instruction includes the ability to let you allocate memory on the system stack
But ultimately, it's your responsibility to do so...

How many bytes to reserve on the stack ?
- Registers that need to be saved:
- Amount of space to reserve on stack:
Stack pointer in SPARC
- Stack point:

The save instruction

The syntax and the effect of the "save" instruction:

save %r1, constant, %r3 or: save %r1, %r2, %r3 Effect: 1. Temp <- r1 + constant (or r1 + r2) 2. CWP <- CWP - 1 (NOTE: this will move the window down !!!) 2. r3 <- Temp

Notes:

The operands %r1 (and %r2 ) are register names used in the original register window.
(I.e., before CWP was decremented)
But the operand %r3 is a register name in the new register window .
(I.e., after CWP has been decremented)

Example: Consider the effect of the execution of "save %o6, -96, %o6":

Before the execution of "save %o6, -96, %o6":
Note that o6 points to the top of the (system) stack

Step 1: compute Temp = r1 + constant

Temp = %o6 + (-96) = 100000 - 96 = 99904

Step 2: update CWP = CWP − 1, result:
Note:

Step 3: update r3 = Temp (%06 = 99904), result:

Note:

We have initialized a "new" stack pointer %o6 !!!
We have allocated 96 bytes on the stack
The allocated space (on the stack) is used to save the window registers in CWP=6

A more common name for %o6
- The register %o6 is more commonly known as:
- The most commonly used form of the save instruction is:
- The save instruction is usually the first instruction executed by a called function
- Illustration: (Demo the effect of advancing register window WITH saving space on stack)
  - Prog file: click here

Sliding the register window backwards

The "restore" instruction:

Syntax: restore %r1, constant, %r3 or: restore %r1, %r2, %r3
Effect: 1. Temp <- r1 + constant (or r1 + r2) 2. CWP <- CWP + 1 (NOTE: this will push the window back !!!) 2. r3 <- Temp

The most common form of restore instruction used is:

restore %g0, %g0, %g0 (which is abbreviated as: restore)

The effect of this trivial restore instruction is simply:

CWP <- CWP + 1

Example:

Before executing the restore instruction:
After executing the restore instruction:
Note:

DEMO: click here

Manipulating the register window: the save and restore instruction of SPARC

Manipulating the register window: the `save` and `restore` instruction of SPARC