the fetch-execute cycle (at a glance)
How does a chip of silicon 'run' a program? Not by understanding it, but by repeating one tiny ritual billions of times a second. That ritual is the fetch-execute cycle: fetch the next instruction from memory, figure out what it says, do it, and move on. A modern computer is, at heart, this loop spinning at extraordinary speed.
Walk through one turn of the loop. A special register called the program counter holds the memory address of the next instruction. The CPU fetches the bytes at that address from memory. It decodes them - works out which operation they encode and which data they involve. It executes - adds two numbers, copies a value, compares them, or jumps somewhere else. Then it advances the program counter to the following instruction (unless the instruction itself changed where to go, which is how loops and decisions work) and starts over. Nothing is magic: each step is just moving and transforming numbers.
Why it matters at a glance: this loop is the bridge between the abstract program you wrote and the physical machine. Understanding that the CPU only ever does fetch-decode-execute demystifies the whole stack - it shows why a program is just instructions in memory, why an infinite loop hangs (the cycle never reaches anything new), and why control flow like if and while ultimately become instructions that adjust the program counter. Real CPUs pipeline and overlap these steps for speed, but the simple loop is the right first picture.
Roughly, to run x = a + b the CPU fetches a 'load a' instruction, executes it, fetches 'load b', executes it, fetches 'add', executes it, fetches 'store into x', executes it - four trips around the loop, each advancing the program counter.
One line of source becomes several fetch-execute turns.
This is the orienting picture, not the full machinery. Real processors fetch many instructions ahead, run them out of order, and overlap stages in a pipeline - but logically each instruction still appears to fetch, decode, then execute.