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.

  • 5
    $\begingroup$ I bet not all "implementations" of the fetch-execute cycle conform to this pseudocode. The exact place where the program counter is incremented seems completely arbitrary. Whoever wrote your textbook had to put it somewhere. $\endgroup$ – Yuval Filmus Jan 17 '17 at 19:31
  • $\begingroup$ @YuvalFilmus I see. I had just assumed that it was there because of it being the same across the two A level computing specifications I've seen (both in the UK), as well as a few websites which I had gone on. $\endgroup$ – Philip Eagles Jan 17 '17 at 19:35
  • 3
    $\begingroup$ They probably all copied from each other. $\endgroup$ – Yuval Filmus Jan 17 '17 at 19:36

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.

  1. 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.
  2. 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.


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.