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.
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.
You don’t actually know that.
What you know from studying the processor’s instruction set is whether instructions using program counter relative addressing are defined to use the location of the instruction itself or the location of the next instruction. That’s something that is defined by the instruction set architecture and is something that can never be changed without breaking all existing applications. But when the processor changes the processor is an implementation detail, and you don’t know.
Actually a modern processor will likely only change the program counter inside the processor when instructions have been committed which may be a long time later.
