0
$\begingroup$

I read a statement in the textbook that : Operand Forwarding cannot remove all RAW Hazards in Pipelined Processor but am unable to conceptualize that in my brain. Can you please explain it with an example where Operand Forwarding will not be able to remove RAW Hazard .

$\endgroup$
1
  • $\begingroup$ Welcome to COMPUTERSCIENCE @SE. a statement in the textbook Please identify the book and indicate where to find that statement - there might be more than one definition what exactly Operand Forwarding means. $\endgroup$ – greybeard Sep 26 '20 at 7:16
2
$\begingroup$

Sure! And I can assure that is a fairly good question, if you are not able to see all the combinations.

See, operand forwarding can indeed remove all RAW hazards inside CPU but it is helpless when not all execution inside the CPU.

What I mean is all the RAW hazard scenarios, that we can write involving REGISTERS only and execution is some ALU operation, operand forwarding can escape the hazard.

like:

r1 <- r2 + r3 : I1
r4 <- r1 - r3 : I2

r1 is being calculated in ALU for I1, while I2 needs to load r1 as operand for ALU. Here the trick is even though you load the operands of ALU for execution, bt ALU will first execute I1 and then I2 in that order. So, even though r1 is not ready at the assigned time for operand fetch phase of I2, but it will be available before ALU starts execution of I2, and thus taking the benefit of same fact:

CPU notes that I2 is wanting the ALU execution output as an operand. So, CPU saves this information as setting a bit inside the circuitry. And allowing I2 to proceed with "OPERAND FETCH PHASE" while skipping fetch of I2.

(Fetch of I2 is actually done, when CPU sees the RAW and sets the bit, but that's just assurance of fetch done, NOT THE ACTUAL FETCH)

THIS IS OPERAND FORWADING!

Now as soon as ALU computes the value, as the bit of oprand forwarding is 1, it transfers the contents of ALU output to the ALU operand.

(NOW THE GUARANTEE HAS BEEN COMPLETE, AND r1 for I2 has been fetched).

But observe, the write to r1 by I1 may be not done yet and in next cycles this be done. But I2 might be in ALU execution phase at this cycle. So, as the FUTURE OPERAND(r1) is inside CPU and ALU being sequential, we could solve RAW.

But the problem is with LOAD/STORE involved in RAW.

load r1, Address1 : I1

r3 <- r1 + r2 : I2

Now the ALU for I2 can't get r1 before complete I1 is executed and r1 has been really written into. So, this time "OPERAND FETCH PHASE" of I2 will have stall and can't proceed.

Hope this helps.

$\endgroup$

Your Answer

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

Not the answer you're looking for? Browse other questions tagged or ask your own question.