The Fetch–Decode–Execute Cycle

PC — program counter

Holds the address of the next instruction. This is the processor's entire notion of where it is; every jump, call, return and interrupt is ultimately a write to it.

MAR — memory address register

Drives the address bus. Separate from the PC so the PC can be advanced while a fetch is still in flight.

MDR — memory data register

Whatever came back from, or is going to, the data bus.

IR — instruction register

Holds the instruction for the duration of its execution, freeing the MDR for operands.

Accumulator and general registers

The working data. On the 8085 the accumulator is privileged: most arithmetic has it as an implicit operand and destination.

Flags

Zero, carry, sign, parity — set as a side effect of ALU operations, and read by conditional branches. This is the only channel by which a computation influences control flow.

1. 1MAR ← PC — put the address of the next instruction onto the address bus.
2. 2MDR ← M[MAR] — memory answers; the data bus carries the opcode back.
3. 3PC ← PC + 1 — advance, on the assumption that execution continues to the next address.
4. 4IR ← MDR — move it into the instruction register, where it will stay until execution finishes.

Nothing in this sequence depends on which instruction is being fetched. That is exactly what allows fetch to be a fixed hardware sequence, and it is why a processor can execute data as though it were code — the fetch has no way to tell the difference.

The increment happening *during* fetch is the reason a jump instruction must overwrite the PC rather than skip. By the time a jump executes, the PC already points past it. This is also why a subroutine call saves the PC's post-increment value: that is precisely the return address.

The instruction decoder maps the opcode bits onto control lines: which register drives the internal bus, which ALU function is selected, whether a memory access is a read or a write. It is a combinational block, so on a simple processor it costs no separate memory cycle.

Decoding also determines the addressing mode — whether the operand is in the instruction itself, in a register, at an address named by the instruction, or at an address held in a register. The mode is what makes the same ADD opcode reach different data.

This is where instructions finally differ. An ALU operation presents its operands and writes back a result plus flags; a load or store causes another memory cycle; a jump writes the PC; a call pushes the PC to the stack first.

One instruction takes one or more machine cycles, each of which is a single bus transaction (opcode fetch, memory read, memory write, I/O). Each machine cycle takes several clock periods, called T-states.

So an 8085 MOV A, B is one machine cycle of four T-states, while LDA 3000 is four machine cycles — opcode fetch, two operand-address reads, and a memory read — taking thirteen. Instruction timing in this subject is exactly this bookkeeping, and it is why counting T-states is how a delay loop is calibrated.

• It cannot idle. There is no state in which a processor is running but doing nothing. HLT stops the clock, and a waiting operating system is executing an idle loop.
• It cannot decide to stop. Nothing in the hardware evaluates whether to continue. The cycle is unconditional.
• It cannot tell code from data. A fetch reads bytes; whether those bytes were meant as instructions is a convention the programmer maintains, and the reason a stray jump produces nonsense rather than an error.
• It has no notion of a program. Programs, processes and functions are patterns imposed on memory by software; the hardware only ever knows the current PC.

An interrupt is the one thing that alters the cycle from outside, and even that is implemented as a forced write to the PC between two instructions — never in the middle of one.