2
$\begingroup$

Results from the execution units are written into the future file when they complete (may be out-of-order). Upon operand fetching, you fetch from the future file and not the architectural register file. But what happens in this case:

FADD R3, R2, R1
ADD R3, R6, R7      
...
SUB R9, R3, R9

the FADD is a floating point add and takes multiple cycles to handle. It finishes later than the ADD so is that result the one that is found in the future register file? The SUB instruction fetches its operands from the future file thus getting the wrong value of R3?

$\endgroup$
  • 3
    $\begingroup$ Write-After-Write hazards are handled correctly by hardware. Whether the designers choose to stall the ADD or suppress the storage of the FADD result is an implementation choice. WAW hazards without a WAR hazard are relatively rare in real code, only occurring after control flow where the compiler cannot determine that the early result is not used. (Using more general register renaming avoids this issue since the FADD and ADD would have different destination registers and the SUB would use the most recently defined destination register for R3 results.) $\endgroup$ – Paul A. Clayton Apr 16 '15 at 12:46
  • $\begingroup$ In the architectural file the results are written in-order, but the future file is written as soon as an instruction completes. In this case the FADD completes later than the ADD (the FADD is a multi-cycle instruction) thus the future file contains the wrong value? $\endgroup$ – gilianzz Apr 16 '15 at 16:07
  • $\begingroup$ My above commont is wrong: the ADD instruction isn't fetched because of the WAW hazard. $\endgroup$ – gilianzz Apr 16 '15 at 21:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.