Instructions that affect windows frames

Instructions that affect windows & frames

In the previous chapter, we briefly discussed the concept of windows that provide limited views of the general-purpose registers on the SPARC processor. Let's explore windowing a bit more now.

There are two SPARC instructions that directly affect the register windows:

• save

• restore

Both of these instructions also affect the stack. We will cover each of these in detail in a moment.

Windows diagrammed

There are several ways to diagram the concept of windowing. As we discuss the save , call , and restore instructions, the method used below will help you visualize how the instructions affect the window view.

Figure 17-3. Processor registers and their corresponding window names

The save instruction

On SPARC systems, when a routine calls another routine, usually the first instruction of the new routine will be a save instruction. The save instruction actually does a lot of work, but we have no fears about it not completing its tasks . The only trap that can occur during a save is a window overflow.

The save instruction is the only instruction that decrements the window pointer, thus preserving the current window. In other words, according to the previous figure, our window view would shift from Window N-2 to Window N-3. As you can see, this would mean that the old output registers, %o0 “%o7 , would be the new input registers, %i0 “%i7 . The old local registers, %l0 “%l7 , would be outside of our new window view; however, we would have access to a new set of eight local registers with which to work.

The second thing the save instruction does for us is to push a new, empty frame onto the stack. Using the caller's stack pointer for reference that is in the caller's register %o6, (yes, which will become the callee's %i6 ), the stack is grown downward by a certain amount and the new stack pointer is saved in the callee's own %o6 register. Here is an example of a save instruction you might see. Note that %sp is simply another name for %o6 .

 save %sp, -0x78, %sp 

The first %sp refers to the caller's stack pointer stored in the caller's %o6 register. The second reference to %sp refers to the callee's stack pointer, which is stored in his own %o6 . This may be easier to understand if you imagine that the window shift takes place between the time the CPU deals with the first and second %sp of the save instruction.

The call and jmpl instructions

Were you surprised to learn that it is the responsibility of the callee and not the caller to shift the windows and adjust the stack via the save instruction? Let's look at how the calling routine affects the callee's registers.

The caller may invoke subroutines via either a call instruction or a jmpl instruction. The call instruction actually has the address embedded in the instruction itself as a 30-bit displacement from the current PC value. This signed offset allows the call instruction to reach any location in memory. The address of the call instruction itself is saved in register %o7 .

 call  disp30  

A long jump ( jmpl ) instruction can be used to call a function if the address is contained in a register. In this case, the address of the jmpl is saved in whatever register is specified in the instruction, although this is normally %o7 . A jmpl looks like the following, where address is the location of the routine we wish to jump to.

 jmpl  address  , %o7 

This instruction says to jump to address , saving the current PC in register %o7 . You know what we plan to do with that saved PC value, right? It's going to become the %i7 value after the save instruction is completed and will be put into the callee's frame at fr_savpc .

Note that the return address is not actually the place we wish to return to, but rather the place we came from.

The restore instruction

Maybe you've already guessed it! restore is the instruction that shifts the current window view back to the caller's window. The restore instruction basically pops the callee's frame off the stack, bringing us back to the previous window and the previous %sp or %o6 . The contents of memory don't actually change.

The restore instruction does not return us to the calling routine. For that, we must perform a jump-and-link or jmpl instruction. It is during this jump instruction that we use the saved PC value in %i7 . Again, this is the value we will see in the callee's stack frame at fr_savpc .

The synthetic SPARC assembly instruction, ret , does the jump for us and really is just the instruction shown below. This instruction says to jump to the location referenced in %i7 plus 8 bytes or 2 full words and save our current PC in %g0 .

 jmpl %i7+8, %g0 

Think of %g0 as the /dev/null of registers. Reading and writing to %g0 always results in a zero. So, even though we say to store the PC in %g0, nothing actually happens. All we are doing is jumping back into the calling routine.

The man in the back wants to know why are we jumping to the saved PC+8 instead of PC+4. A good question!

The architecture of SPARC processors includes a pipeline. This pipeline overlaps execution of instructions, so that while the call that got us here was being processed , the next instruction was being fetched and started. Therefore, while we are doing the jump to the new routine, we are actually also executing the instruction at PC + 4. When we return to the calling routine, we are returning to the next instruction that we have not yet executed , which is at PC+8.

Note

For conditional branch instructions, there is a way of saying "Please don't execute the delay instruction, just do the branch"; however, no such feature exists for jmpl .

Okay, now it's time for us to return to our calling routine. This is done with two instructions. The first is the jump instruction. The second command shifts the window. Remember, even though we have jumped, the restore instruction gets executed by virtue of the SPARC pipeline architecture ” it's in the delay slot. So, finally, here is what you can expect to see at the end of a routine.

 ret  restore 

Window overflows & underflows

Hopefully, you've a funny feeling that there's still a piece missing, because there is. We've talked about how the SPARC registers are used and how our windowed view of them changes when the save and restore instructions are executed. But who actually writes the register values into the stack frame in memory?

The short answer is: the operating system.

There is a WIM (Window Invalid Mask) register that keeps track of which windows are in use. There's also a CWP (Current Window Pointer) field in the PSR (Processor Status Register) that keeps track of which window is currently in view. These are discussed in more detail in Appendix A.

Whether you have 40 registers available or 4000, there are a limited number of windows on any system. At some point in time, when we try to execute a save, we will run out of windows and have to start recycling those we've already used. This condition is recognized by the hardware, through use of the WIM and the CWP, and triggers a window overflow trap.

The window overflow trap must be processed by the operating system. When the operating system is UNIX, the kernel moves the window registers onto the stack in memory for safekeeping. It also handles the restoration of window registers via the window underflow trap, which occurs when you have restored so often you need to retrieve old information from the stack.

Window overflows and underflows start occurring early on in the execution of the UNIX operating system. It is only down in the lowest levels of the kernel that we would ever see instances where window overflows and underflows do not occur.

While technically incorrect, it is probably safe for UNIX users on SPARC processors to think of the save instruction as being the one that puts the values of the new input registers into the callee's stack frame. However, it is important to remember that for each different hardware architecture that you encounter, you will invariably find differences at this low level, both in the hardware involved and in the UNIX kernel for that hardware.