Delayed Control Transfer Instructions

The instructions of a routine are normally executed sequentially. However, there are often times when execution needs to skip over some instructions and continue at another, nonsequential location. Programmers often refer to this change in the order of program execution as a "branch" or "jump." And, appropriately, the instructions that perform this task are often called "branches" or "jump instructions."

In SPARC terms, we refer to all instructions that alter the order of instruction execution as "control transfer instructions."

There are basically two types of branches that may be performed by computers. These are:

• Unconditional branches ” Simply change the order of instruction execution

• Conditional branches ” Change the order of execution only when a certain condition is found to be true

Due to the pipeline, the SPARC processor is actually processing more than one instruction at a time. As you know, this is a big advantage when we are executing a sequential sequence of instructions. However, what happens when we need to test for a certain condition and, based upon the result, branch away from the sequence of instructions, instructions that are already being processed in the instruction pipeline ?

On SPARC processors, all but one of the control transfer instructions will, unless specifically told otherwise , execute the instruction that immediately follows it into the pipeline. The instruction following the control transfer instruction is referred to as the "delay instruction" because it is executed during the time delay between execution of the control transfer instruction and execution of the instruction stored at the new location to which control was transferred.

Let's look at this concept from a programmer's point of view. See if you can figure out the order in which the following sequence of English commands might be executed on a SPARC processor.

 1. Load "5" into Register 1  2. Jump to Step 7  3. Load "10" into Register 2  4. (other stuff)  5. (other stuff)  6. (other stuff)  7. Store contents of Register 2 into location X 

In this sequence, the execution sequence would be 1-2-3-7. Is this what you expected?

We load a 5 into Register 1. Next, we jump to Step 7. Since Step 7 was not part of the sequential order of instructions, it must be loaded into the instruction pipeline. Meanwhile, Step 3, which was nearly all of the way through the pipeline, is completed, and Register 2 ends up containing a 10.

Instead of the CPU sitting idle while waiting for the store instruction at Step 7 to be processed through the pipeline, the CPU is kept busy with the execution of the delay instruction, the instruction at Step 3. This is a much more efficient use of the CPU.

When you look at system crash dumps, you will often find nop instructions being used as the delay instruction. This instruction has no effect and is used to fill the delay time slot. Other times, you will see examples more like the one above, where a value is set and will be used after the branch is completed. It is up to the compiler or the assembly language programmer how to make best use of the delay instruction.

Later, when we talk about the stack, we'll see a very common use of the delay instruction.

Note

The Trap on Integer Condition Code, or Ticc instruction, is the only SPARC control transfer instruction that never executes the delay instruction.

Note

Most of the control transfer instructions have an annul bit that can be set to say "don't execute the delay instruction under certain conditions."