Reputation: 16998
Wikipedia's Hazard (computer architecture) article:
Write after write (WAW) (
i2
tries to write an operand before it is written byi1
) A write after write (WAW) data hazard may occur in a concurrent execution environment.Example For example:
i1. R2 <- R4 + R7 i2. R2 <- R1 + R3
The write back (WB) of
i2
must be delayed untili1
finishes executing.
I haven't understood this.
What is the problem if i2
is executed before i1
?
Upvotes: 4
Views: 6397
Reputation: 365277
It's not execution that's the problem; it's only write-back that prevents out-of-order execution of these instructions (if you didn't do register renaming).
The final result in R2
(as seen by other later instructions after this pair) has to match program order, so it has to have the result of the 2nd instruction.
This is why modern out-of-order execution CPUs use register renaming (Tomasulo's algorithm) instead of just scoreboarding: it totally negates WAW and WAR hazards. See the first section of my answer on Why does mulss take only 3 cycles on Haswell, different from Agner's instruction tables? for another explanation in theoretical terms of how register renaming makes reuse of the same register for different results not a problem.
Also see Deoptimizing a program for the pipeline in Intel Sandybridge-family CPUs where I also explain that WAW and WAR anti-dependencies can't cause stalls on modern out-of-order execution CPUs.
For writes to memory (instead of registers), the store buffer takes care of hiding WAW and WAR hazards.
Upvotes: 7
Reputation: 5265
Both operations affect R2
. If i2
write back occurs before the write back of i1
, but the write back of i1
does eventually occur, then R2
will have the result of R4 + R7
instead of the value of R1 + R3
.
The WAW Hazard is about result values being overwritten by a subsequent write that should not have overwritten that value.
Upvotes: 6