Why does the program counter increment before an instruction is completed?

During the fetch, decode, execute cycle, the Program Counter (PC) increments after the operand is copied from the Memory Data Register (MDR), and then carries on with the processing of the instruction.

Why does the PC increment in the middle of the cycle rather than at the end?

My only guess would be that it relates to jump instructions being incremented but I cannot find any sources on this.

The exact details of when (or even how) to increment the program counter are implementation specific details. There are however a few considerations that come into play across most computers.

• After sending out the PC address, there is (almost) always a delay waiting for memory to respond. Thus there's often not a lot going on. One possible use of this "dead" time to do something useful, like incrementing the PC.

• The next instruction is going to need the incremented value of the PC before it can proceed. If the processor does this at the end of the instruction, then the PC increment becomes part of the critical path for the next instruction.

The thing is, once this becomes part of the programming model for a processor, it is difficult to change the outward semantics of the PC increment. Consider processors with a PC relative addressing mode. If the value retrieved were to change from incremented to non-incremented, almost all the code would break. Thus the decisions made for early versions of a CPU must be honored in later (pipelined/overlapped/multi-way executing/multi-threaded/etc) versions of that CPU family.

Finally, and while silly sounding, most important; People are just used to having processors work that way. Some really great gains would be needed in order to ignore this bit of orthodoxy.

StackExchange Computer Science Q#68872, answer score: 10