0
I1:LW R1, 0(R4) ; R1 ← address (0+R4)
I2:ADDI R2, R1, #8 ; R2 ← R1+8
I3:MULT R3, R1, R1 ; R3 ← R1*R1
I4:SW R3, 4(R2) ; address(4+R2) ← R3

In the MIPS code above, in an solution sheet, a true dependency is marked as I3->I4 for R3. From my understanding true dependencies are RAW(read after write) hazards or flow hazards. I am pretty sure though that this is an write after write hazard and therefore not a true dependency. Am I correct to say this?

IRTFM
  • 258,963
  • 21
  • 364
  • 487
HotWheels
  • 444
  • 3
  • 23

1 Answers1

2

write after write hazard

No, this is not a write after write hazard.  While I4 appears to be a write operation — and relative to memory it is indeed a write operation — from a micro architectural point of view, i.e. inside the processor alone where the pipeline stages and registers are located and operate, a store instruction has two source operands and no register target.

So, R3 is read by I4 after being written by I3.  (In other words, the store instruction requires the value of R3, as the value fed to perform the memory store; R3's value is fed to the data memory, along with the address of where to store, and size, here 4).  Thus, this is a read after write hazard.

Peter Cordes
  • 328,167
  • 45
  • 605
  • 847
Erik Eidt
  • 23,049
  • 2
  • 29
  • 53
  • In a slightly more advanced pipeline with a store buffer, stores and loads have to make sure they see each other properly. But if memory access happens in the same pipeline stage for loads as for stores, store-forwarding by probing the store buffer means you never have to stall for store/reload (RAW of a memory location) in a scalar pipeline (1 insn per clock), assuming store-forwarding latency is only 1 cycle. Unlike with the register file, which is read by Decode, written by the write-back stage, which makes RAW hazards a problem. – Peter Cordes Oct 28 '20 at 02:56
  • Stores do have a memory destination, and that can matter in some designs. But not a *register* destination; that's why I added that qualifier to that sentence. – Peter Cordes Oct 28 '20 at 02:57
  • @PeterCordes, thanks for the additional insights (and improved phrasing)! – Erik Eidt Oct 28 '20 at 03:54
  • I forgot to link https://en.wikipedia.org/wiki/Memory_disambiguation#Avoiding_WAR_and_WAW_dependencies and https://blog.stuffedcow.net/2014/01/x86-memory-disambiguation/. Further reading re: preserving program ordering with out-of-order store execution, and avoiding stalls on store->reload with OoO exec. (It can get really tricky when a store address might not be ready until *after* the later load address; modern x86 CPUs dynamically predict whether a load is a reload of an unknown-address store or not, and may need to flush the pipeline if they guess wrong.) – Peter Cordes Oct 28 '20 at 18:30