|
|
|
|
|
|
|
The AG of * is delayed by five cycles. |
|
|
|
|
|
|
|
|
The store instruction is another instruction that may slow down program execution. It is relatively common in code (especially unoptimized code) for a store instruction that puts away a particular register to immediately precede a load instruction that puts a new value in that same register. |
|
|
|
|
|
|
|
|
The store (*) cannot be completed until the preceding instruction (* - 1) has completed execution and determined the final value for the same register, R1. The load (* + 1) cannot be executed until R1 is freed by the execution of the store instruction. Sequences such as those shown below (case 4) are common enough that store buffers are frequently used. Here R1 is freed one cycle after a final value is established, after the data in R1 has been transmitted to the store buffer (SB). The problem described in this case is actually one of naming. Instructions starting with * + 1, the load, are independent of the instructions preceding it, at least insofar as their usage of R1 is concerned. The problem is simply that instructions * and * + 1 use the same name (R1). We consider this issue in Chapter 7. |
|
|
|
|
|
|
|
|
Without store buffers, we have: |
|
|
|
|
|
|
|
|
The * + 1 execution is delayed six cycles. To avoid this, special store buffers are used to hold pending stores. |
|
|
|
|
|
|
|
|
With store buffers, we have: |
|
|
|
|
|
|
|
|
As a further optimization, R1's availability could be anticipated so that the DF in * + 1 could begin three cycles before R1 is available. |
|
|
|
|
|
|
|
|
Certain instruction pairs, such as LD/ST, ST/ST, and ST/LD may also create dependencies as a resource conflict. The LD and ST do not always use |
|
|
|
|
|
