WebEE

 

Stores
The store instruction exhibits the same data hazards as, for example, arithmetic instructions such as add or sub. Consider the following program:

add r1, r2, r3
s 10(r0), r1 memory[10] :=r1

To solve the hazard, we have the usual three options:

1.	Copy the result from B (effectively, from the register file) to SMR and ignore any dependencies. In effect, leave the hardware as it was.
2.	Stall the pipeline. This results in a two-cycle penalty
3.	Use forwarding. This requires an additional multiplexer (MUX8) and connections from OUT0 and OUT1 (connections marked 3 and 4)

Note that, conceptually, this is not a new problem (it is the exact same data hazard as we saw before). It is treated separately here, however, because we do need a bit of extra hardware to resolve the hardware for stores.

 

Control Hazards
Consider the following code sequence:

	add r1, r2, r3
	j l1	// Jump to (label) l1
	sub r2, r3, r0
11:	xor r3, r0, r1
	ori r1, r2, 10

 

How this is executed in the MIPS pipeline?

Cycle	IF	ID	EX	MA	WB
1	add
2	j	add
3	sub	j	add			The branch is resolved here, but we already fetched the sub
4	xor	sub	j	add
5	ori	xor	sub	j	add

 

Notice that we executed the sub instruction which, logically, should never have executed because of the branch (j). This happens because the branch target is only calculated in the ID phase. This problem is called a control hazard.

As with load hazards, we can decide to ignore the control hazard. Once we define that the instruction directly after the branch is executed anyway, we can take that into account and make use of it. This technique is called delayed branches, and the instruction following the branch is said to be in the delay slot.

Try it out. Run this program using delayed branches.