The concept of pipelining of instructions in a computer is well known. The processing of a single instruction is performed in a number of different stages, such as fetching, decoding and execution. In pipelined computers, each of the various stages are working on different instructions at the same time. For example, if the pipeline was only three stages long, the first instruction that has passed through the pipeline is being operated on by the third stage while the second instruction to enter the pipeline will be operated on by the second stage, and while the third instruction to enter the pipeline is being operated on by the first stage. Pipelining is a much more efficient method of processing instructions in comparison with waiting for a single instruction to be completely processed before beginning the processing of a second instruction. In a normal flow of a computer program, it is easy to know which instruction is to enter the pipeline next. In most instances, it is the sequentially next instruction that enters the pipeline so that, for example, instruction 101 will enter the pipeline after instruction 100.
One exception to this normal flow of control is known as a subroutine. A subroutine is a program or a sequence of instructions that can be "called" to perform the same tasks at different points in a program, or even in different programs. For example, instruction 101 may call for a subroutine which begins executing at instruction 200. The subroutine may execute instructions 200-202 and then "return" to the main flow at instruction 102. Further, the same subroutine, comprising instructions 200-202, may be called from a number of different locations in the main flow and return to different locations in the main flow.
Subroutines pose a problem for heavily pipelined computers (those with many stages in the pipeline). Although the instruction which calls a subroutine will contain enough information to determine which is the next instruction to enter the pipeline (i.e., the first instruction in the called subroutine), the return instruction in the subroutine will not contain such information. Instead, a return instruction must pass through all of the stages of the pipeline before the return address will be known from the return instruction. If the computer waited for the return instruction to pass through the pipeline before entering another instruction, there would then be a "bubble" in the pipeline behind the return instruction in which there would be no instructions, thereby lowering the performance of the computer.
To avoid bubbles, a mechanism known as a stack has been used. Basically, a stack will store the return address at the time a subroutine is called, and when the subroutine is completed and control is returned to the main flow by a return instruction, this return address is located in the stack and provided to the pipeline. The pipeline will then be able to return the control to the main flow by entering the proper instruction into the pipeline. By keeping a stack of the return addresses, and using these return addresses to locate the next instruction when there is a return from the subroutine, bubbles in the pipeline are eliminated.
A problem with the stack mechanism is the limited size of the stack and the complicated procedures to deal with stack overruns and underruns when there are a large number of subroutines that have been called. In other words, if the stack contains twelve locations, only twelve subroutines can be called at one time without resorting to the complicated procedures for stack overruns.
There is a need for a mechanism that provides return addresses and eliminates bubbles in the pipeline, but without requiring the complicated procedures necessary when a stack is used.
USPTO Backgrounds
USPTO Backgrounds