Asynchronous Events

The CPU's normal behavior is a sequential fetch-and-execute process.

Programming

Why the Ordinary Path Comes First

Asynchronous events are things that happen outside the CPU's normal flow of work, such as an event that arrives while a program is partway through its instructions. To understand what such an event disrupts, you first need a clear picture of what the CPU does when nothing unusual is happening. The source material establishes that the CPU's normal behavior is a sequential fetch-and-execute process. Everything that comes later about polling loops and interrupts is an answer to the question of what happens when that sequence is not simply allowed to run from start to finish.

Instructions as Binary Patterns

A program that the CPU executes is made of machine language instructions, and each instruction is stored as a binary pattern, meaning a pattern of 0s and 1s. An instruction is not a human-level explanation such as 'add these two numbers' written in words. The CPU does not read sentences; it works with the bit patterns themselves. Reading a program's binary form tells you nothing in plain language until someone decodes it, which is why machine language is so hard for people to write directly.

Think of a binary instruction as a fixed-length code. The same kind of pattern can mean one operation when it appears in one place and a different operation when it appears in another. The meaning lives in the hardware's design, not in the pattern alone. This is why an instruction is only meaningful to the CPU that is built to read it.

Example

Illustrative only, not a real instruction set: suppose the bit pattern 0101 stands for the operation 'add' and the pattern 1100 stands for 'store'. A memory cell holding 0101 is then an instruction, while a memory cell holding 1100 is a different instruction. Neither cell says anything in English; the CPU only acts on the pattern it reads.

Where Programs Live: Memory and Storage

A program stored on a hard disk or solid state drive cannot be executed directly, according to the model this material uses. It must first be loaded into main memory, and the CPU's instruction-fetching activity takes place through main memory. Main memory serves as the temporary execution workspace. It is comparatively limited in size and it is volatile, meaning its contents are not kept when power is removed. Storage devices provide permanent storage for larger amounts of information.

What is kept in main memory while the CPU works, what is kept on storage, and what happens to main memory contents when power is removed?

Tracing the Fetch-Execute Cycle

The CPU's ordinary behavior is a repeating cycle. It fetches an instruction from main memory, executes that instruction, and then goes back to fetch the next one. The source describes this as a sequential process, so the instructions are handled one after another in their order. The diagram below shows the loop; follow it with the steps that come after it.

What happens in order, and where does the CPU go back to after each instruction is executed?

1
The CPU fetches one instruction, a binary pattern, from main memory.
2
The CPU executes that instruction.
3
Once execution finishes, the CPU returns to fetch the next instruction.
4
The loop repeats, so instructions are processed in their sequential order.

Worked example

Tracing four instructions through the cycle

Main memory holds four instructions in order: A, B, C, D. Trace which instruction the CPU fetches and executes at each stage, and explain where the cycle returns after each execution.

1
Fetch 1
The CPU fetches instruction A from main memory.
2
Execute 1
The CPU executes A. Execution finishes, and control returns to fetching.
3
Fetch 2
The CPU fetches instruction B, the next one in the sequence.
4
Execute 2
The CPU executes B and returns to fetching.
5
Fetch 3 and 4
The same pattern repeats for C and then D.

Result

The CPU runs A, B, C, D in order, each time returning to fetch the next instruction after finishing the current one.

When the Sequence Is Broken

The fetch-execute cycle describes what happens when nothing outside the sequence intervenes. An asynchronous event is something that arrives from outside that ordinary sequence, and the source material describes such events as not fitting neatly into the CPU's ordinary instruction sequence. The flowchart below places an outside event on top of the normal loop and asks the question that the rest of this topic is built around: does the event change which instruction runs next?

How does an event arriving from outside the normal instruction sequence change which instruction the CPU runs next?

In the ordinary case the answer to the decision is no, and the loop simply continues. The yes branch is where the study of asynchronous events begins. Notice that this topic is introduced as a departure from the sequence rather than as part of it. You cannot describe the departure clearly until the sequence itself is clear.

What do you think happens?

If power is removed from the computer while a program is running, which of these survives: the instructions held only in main memory, or the program saved on a hard disk?

The instructions held only in main memory
The program saved on the hard disk

Reveal answer

Answer:

The program saved on the hard disk survives. Main memory is volatile, so the instructions held only there are lost.

Main memory is the temporary workspace and is volatile. Storage devices provide permanent storage, so a saved program can be loaded into main memory again.

Common Misreadings of the Cycle

Common mistake
Treating an instruction as a readable English command
What it looks like
Assuming that a stored instruction literally says 'add these numbers' in a form a person can read.
Why it fails
Instructions are binary patterns. Their meaning is only recovered by hardware built to interpret them.
Do this instead
Think of each instruction as a bit pattern that the CPU decodes according to its design.
Common mistake
Assuming a saved program runs directly from disk
What it looks like
Believing that double-clicking a program on storage makes the CPU execute its instructions straight off the drive.
Why it fails
The model used here says a program must first be loaded into main memory, because instruction fetching takes place through main memory.
Do this instead
Loading into main memory comes before execution, and the CPU fetches from that workspace.
Common mistake
Assuming main memory keeps its contents permanently
What it looks like
Expecting work held only in main memory to still be there after power is removed.
Why it fails
Main memory is volatile, while storage devices provide permanent storage.
Do this instead
Keep anything that must survive a shutdown in storage, not only in main memory.
Common mistake
Thinking the cycle skips instructions at random
What it looks like
Imagining the CPU picking whichever instruction seems most useful next.
Why it fails
The ordinary behavior is described as sequential fetch-and-execute.
Do this instead
In the ordinary path, the next instruction is the next one in the sequence, and events that break this pattern are a separate topic.

Trace It Yourself

EASY

Main memory holds five instructions in order: P, Q, R, S, T. Without looking back, write the order in which the CPU fetches and executes them under the ordinary sequential cycle, and state where the cycle returns after executing R. Then explain in one sentence why the program must be in main memory before any of these steps can happen.

Hints

Follow the loop: fetch, execute, return, then fetch the next instruction in sequence.
Recall that the CPU fetches from main memory, and that storage is not the execution location.

Your attempt (not saved)

MEDIUM

Suppose an outside event arrives in the middle of executing instruction Q. Using the flowchart, describe which branch the decision follows, and state what this means for the claim that the ordinary path is sequential. Do not try to explain how the CPU handles the event; that comes later.