|
|
|
| Table 4.15 Store/fetch interlock. | | Occurrence by Number of Instr between Store and Fetch | Occurrence within This Type of Interlock | | | | | | | | | | | | | | | | | | | | Total occurrence of this interlock |
| |
|
|
|
|
|
|
Store-Fetch Interlock Delays |
|
|
|
|
|
|
|
|
A store-fetch interlock condition exists whenever an instruction requires an operand from storage but the operand is unavailable because it will be modified by some preceding, uncompleted instruction. Consider the following example, which was found in a major control program by Rymarczyk [250]. The move character instruction (MOVE. C) stores into its operand (workarea) during the last step of its execution, and the subsequent compare character instruction needs to fetch from the modified storage area. Consequently, the compare character instruction is unable to perform its operand fetch step (DF) until after the MOVE. C instruction completes its putaway step (PA), resulting in a substantial pipeline disruption. |
|
|
|
 |
|
|
|
|
MOVE.C WORKAREA, USER
CMP.C #C, WORKAREA+7 |
|
|
|
|
|
|
|
|
To determine the potential for a store-fetch interlock delay, one needs to know the distribution of distances between instructions that store a result into a particular storage location and those that use this location as an operand source. |
|
|
|
|
|
|
|
|
This dependency occurs in 7% of the executed instructions; of these, 56% require a fetch based on the preceding instruction's store. Table 4.15 shows a distribution for the general environment. |
|
|
|
|
|
