RAW and WAW hazard avoidance

[Gravis]

i was curious as to how RAW and WAW hazards are known to an instruction. as far as i can figure, there are 64 bits to mark for which registers are being read and another 64 for which register will be written to by the previous instruction. then this lock is checked against the current instruction until the ones to be used are freed up (by the last instruction) at which point it proceeds with the current instruction.

is this correct or perhaps there is just a single set of 64 bits which ends up blocking RAR? is there a better way to do this?

anyway it goes, do instructions get delayed and then lock registers at the beginning RA pipeline stage?

[timpart]

Well here is one way it could work which I think comes up with the right answer.

Have a 64 entry boolean array to indicate register waiting for a write. All start as false.

Do the RA pipeline stage after E1 to E4 happening at the same time for other instructions.

In E1 / E2 /E4 if the instruction is completing here then set the waiting for a write of the destination register to false.

In RA check whether any of the registers being read are waiting for a write. If so stall the instruction here (effectively inserting a NOP into the pipeline) This avoids RAW.

Then in RA check whether the register being written to is waiting for a write. If so stall the instruction here (effectively inserting a NOP into the pipeline) This avoids WAW.

Then in RA set the waiting for a write of the destination register to true.

Tim

[Gravis]

[EggBaconAndSpam]

locked_for_writing &= ~want_to_write; might be clearer.

On a different note: How comes that the architecture manual states a 1 cycle stall between IALU and FPU instructions (with register dependency)?

[Gravis]

[EggBaconAndSpam]

Well FPU-IALU makes sense, RA to E4 would be 4+1 cycles, however IALU-FPU is actually the same as IALU-IALU and would be 0+1 cycle...

Maybe they incorporated dual-issuing into their numbers?...

[timpart]

[timpart]

[EggBaconAndSpam]

[timpart]