I came across a question while preparing for an exam. The question is
Consider the following y86 code snippet when answering the following questions about implementation of the conditional jump in the 5 stage pipeline presented in class, with stages F, D, E, M, WB.
1: irmovq $8, %rsi
2: irmovq $1, %r9
3: jmp label1
4: label2: addq %rsi, %r10
5: label1: subq %r9, %rsi
6: jne label2
7: andq %rbx, %rdx
8: irmovq $10, %r10
9: halt
a. When the jne instruction has completed the F stage, is the address of the next instruction available in the processor? Circle one
YES NO
b. If the processor assumes the conditional jump is TAKEN, in which pipeline internal register (variable) is the address of the next instruction when the jne instruction finishes the F stage? Circle one icode ifun rA rB valC valP valM valE
c. If the processor assumes the conditional jump is NOT TAKEN, in which pipeline internal register (variable) is the address of the next instruction when the jne instruction finishes the F stage? Circle one
icode ifun rA rB valC valP valM valE
d. After which stage will the pipeline know whether the conditional jump should be taken or not? Circle the correct stage
F D E M WB
I have the answers without explanation Here are the answers:
1) YES
2) valC
3) valP
4) E
Can someone PLEASE, PLEASE explain the process. I have an exam and I really need help.
After which stage will the pipeline know whether the conditional jump should be taken or not? Circle the correct stage
Some in-order pipelined CPUs may handle branch taken/not-taken in the Decode stage, to make it only a 1 cycle bubble in the pipeline. (Update: I had previous thought classic MIPS did this, but in fact it achieves a branch latency of 1 cycle with a different trick, evaluating the branch condition in the first half-cycle of EXEC, still letting it fully hide the control dependency / hazard: https://en.wikipedia.org/wiki/Classic_RISC_pipeline#Control_hazards).
A design that stalls or speculates until the branch reached Execute is viable too, but lower performance.
So this question seems un-answerable, unless you have some other clue about how your y86 classic 5-stage pipeline is designed.
Resolving branch direction in Decode would require the flags to be ready sooner, so cmp or sub followed by jcc would always cause a stall for the data dependency. Checking flags is even easier than checking a register after decoding which register needs to be checked, and reading it from the register file. (MIPS doesn't have flags; it has instructions like beq $t1, $t2, target to branch on equality (which can be done with less latency than a subtract), or bltz $t1, target to check the sign bit of one reg.
That would tend to cause extra stalls when branching on something you just calculated, which is why MIPS I didn't do it that way: How does MIPS I handle branching on the previous ALU instruction without stalling?
I'm not sure if any real CPU ever did decide branch direction as part of decode; it seems problematic and might have just been a misconception I picked up about MIPS I at some point. But it is at least theoretically possible.