P-1.1 What the Machine Actually Executes

What this is and why it exists

Most people learn a language before they learn what a computer does with it. They then spend years with a fuzzy picture of both, and it shows up as surprise. Surprise that one program is slow. Surprise that a language can be compiled and interpreted, or at what an error message means.

The underlying picture is simpler than the fog around it. A processor executes a small, dull set of numeric instructions. Everything else — every language, every compiler, every runtime — is a scheme for producing those instructions.

See that once and a lot of later confusion never forms.

The vocabulary

• Processor — the part that executes instructions. It reads numbers and acts on them.
• Instruction — one numbered operation the processor knows: add these, load that, jump there.
• Cycle — one turn of the processor's loop.
• Machine code — instructions as numbers, which is the only thing a processor can run.
• Source code — the text you write, which a processor cannot read.
• Compiler — a tool that translates a whole source file into machine code before the program runs.
• Interpreter — a tool that reads source and acts on it while the program runs.
• Implementation — a particular tool for a particular language. This word is the point of the topic.

The mental model

A processor repeats a very short loop, forever: fetch the instruction at a numbered location, decode what it means, execute it. Then the next one. Everything a computer appears to do is that loop running billions of times a second.

That loop reads numbers, not text. So the gap between your source file and a running program is the business of getting from one to the other. There are two ways to do it. A compiler translates the whole file ahead of time and hands the processor machine code. An interpreter reads your source while the program runs and acts on each piece as it goes. Most real systems do some of both — translating to an intermediate form ahead of time, then executing that.

Here is the idea that clears the most confusion, and it is worth stating flatly. Compiled and interpreted are properties of an implementation, not of a language. There is nothing about C that requires compiling and nothing about Python that forbids it. The distinction belongs to the tool you run your code through. This is why one language often has several implementations with very different performance. It is also why "that language is slow" is usually about a tool rather than a language.

Which brings us to speed. When one program runs faster than another on the same problem, the difference is about timing. How much work happens *while the program runs* rather than before it. Checking types costs time. Looking up a name in a table costs time. Asking the operating system for memory costs time. A tool that does those things ahead of time, once, produces something that does less work per second of running.

Knowing where that work went is where the ability to make anything faster begins. Without it, performance is superstition.

What you should now be able to explain or do

Describe the processor's loop in three words and say what each one does. Explain why a processor cannot run your source file. Say what a compiler and an interpreter each do, and when a real system does both. State why compiled and interpreted describe an implementation rather than a language, and give the consequence. Explain where the time goes when one program is slower than another. Take a program of three or four lines and account for every stage between the text and the output.

Check yourself