4
$\begingroup$

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.

$\endgroup$
  • 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
8
$\begingroup$

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.

$\endgroup$
1
$\begingroup$

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.

$\endgroup$

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.