Scheduler which retries load/store hit situations

Details Scheduler which retries load/store hit situations Scheduler which retries load/store hit situations

2000-01-03

2003-09-16

Coleman, Eric (Department: 2154)

Electrical computers and digital processing systems: processing

Processing architecture

Superscalar

C712S214000, C712S216000

Reexamination Certificate

active

06622235

ABSTRACT:

BACKGROUND OF THE INVENTION
1. Field of the Invention
This invention is related to the field of processors and, more particularly, to instruction scheduling mechanisms within processors.
2. Description of the Related Art
Superscalar processors attempt to achieve high performance by issuing and executing multiple instructions per clock cycle and by employing the highest possible clock frequency consistent with the design. One method for increasing the number of instructions executed per clock cycle is out of order execution. In out of order execution, instructions may be executed in a different order than that specified in the program sequence (or “program order”). Certain instructions near each other in a program sequence may have dependencies which prohibit their concurrent execution, while subsequent instructions in the program sequence may not have dependencies on the previous instructions. Accordingly, out of order execution may increase performance of the superscalar processor by increasing the number of instructions executed concurrently (on the average). Another method related to out of order execution is speculative execution, in which instructions are executed subsequent to other instructions which may cause program execution to proceed down a different path than the path containing the speculative instructions. For example, instructions may be speculative if the instructions are subsequent to a particular instruction which may cause an exception. Instructions are also speculative if the instructions are subsequent to a predicted conditional branch instruction which has not yet been executed. Similarly, instructions may be out of order or speculatively scheduled, issued, etc.
Unfortunately, scheduling instructions for out of order or speculative execution presents additional hardware complexities for the processor. The term “scheduling” generally refers to selecting an instruction for execution. Typically, the processor attempts to schedule instructions as rapidly as possible to maximize the average instruction execution rate (e.g. by executing instructions out of order to deal with dependencies and hardware availability for various instruction types). These complexities may limit the clock frequency at which the processor may operate. In particular, the dependencies between instructions must be respected by the scheduling hardware. Generally, as used herein, the term “dependency” refers to a relationship between a first instruction and a subsequent second instruction in program order which requires the execution of the first instruction prior to the execution of the second instruction. A variety of dependencies may be defined. For example, a source operand dependency occurs if a source operand of the second instruction is a destination operand of the first instruction.
Generally, instructions may have one or more source operands and one or more destination operands. The source operands are input values to be manipulated according to the instruction definition to produce one or more results (which are the destination operands). Source and destination operands may be memory operands stored in a memory location external to the processor, or may be register operands stored in register storage locations included within the processor. The instruction set architecture employed by the processor defines a number of architected registers. These registers are defined to exist by the instruction set architecture, and instructions may be coded to use the architected registers as source and destination operands. An instruction specifies a particular register as a source or destination operand via a register number (or register address) in an operand field of the instruction. The register number uniquely identifies the selected register among the architected registers. A source operand is identified by a source register number and a destination operand is identified by a destination register number.
In addition to operand dependencies, one or more types of ordering dependencies may be enforced by a processor. Ordering dependencies may be used, for example, to simplify the hardware employed or to generate correct program execution. By forcing certain instructions to be executed in order with respect to certain other instructions, hardware for handling consequences of the out of order execution of the instructions may be omitted. For example, instructions which update special registers containing general processor operating state may affect the execution of a variety of subsequent instructions which do not explicitly access the special registers. Generally, ordering dependencies may vary from microarchitecture to microarchitecture.
While the scheduling mechanism respects dependencies, it is desirable to be as aggressive as possible in scheduling instructions out of order and/or speculatively in an attempt to maximize the performance gain realized. For example, it may be desirable to schedule load memory operations prior to older store memory operations, since load memory operations more typically have dependent instructions. However, in some cases, a load memory operation may depend on an older store memory operation (e.g. the store memory operation updates at least one byte accessed by the load memory operation). In such cases, the load is incorrectly executed if executed prior to the store memory operation. A mechanism for allowing load memory operations to be scheduled prior to older store memory operations and for discovering and recovering from incorrect execution of a particular load memory operation prior to a particular older store memory operation is therefore desired.
Additionally, memory operations may experience additional conditions over and above the dependencies which may prevent correct execution. For example, memory operations often require additional resources to complete execution. For example, memory operations which miss a data cache within the processor may require a miss buffer entry to store the address of the memory operand for fetching from main memory. Load memory operations may have a memory operand updated by one or more stores in a store buffer, but the data may not be available or cannot be forwarded via the hardware associated with the store buffer. A scheduling mechanism which handles such situations is therefore desired.
SUMMARY OF THE INVENTION
The problems outlined above are in large part solved by a scheduler as described herein. The scheduler issues memory operations without regard to whether or not resources are available to handle each possible execution outcome of that memory operation. The scheduler also retains the memory operation after issuance. If a condition occurs which prevents correct execution of the memory operation, the memory operation is retried. The scheduler subsequently reschedules and reissues the memory operation in response to the retry. Advantageously memory operations may be aggressively scheduled and, if the memory operations do not complete execution, the memory operations are rescheduled again at a later point. Many memory operations may complete successfully during the initial issuance, and those memory operations which do not complete successfully are completed during a subsequent reissue (although some memory operations may be reissued multiple times before completing).
Additionally, in one embodiment, the scheduler may receive a retry type indicating the reason for retry. Certain retry types may indicate a delayed reissuance of the memory operation until the occurrence of a subsequent event. In response to such retry types, the scheduler monitors for the subsequent event and delays reissuance until the event is detected. For example, a load memory operation which misses the data cache is reissued to cause the memory operand to be stored into the destination operand. However, reissuance of the load memory operation is delayed until the fill data including the memory operand is being provided. Then, the load memory operation is reissued and may complete by receiving the fill data. As another example, a particular me

Affiliated with

Also associated with

Rating

Scheduler which retries load/store hit situations does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with Scheduler which retries load/store hit situations, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Scheduler which retries load/store hit situations will most certainly appreciate the feedback.

Rate now

Comments { 0 }

Profile ID: LFUS-PAI-O-3063754