Machines and Low-Level Programs

This is Unit Four of Computer Science: computational models and languages. The unit's central fact arrives early and surprises people. A computer never executes the code anybody wrote. Every program above the lowest level is translated down before anything happens — and what runs is a sequence of binary digits, which is the only model a machine can actually execute. Everything above that exists for people. Languages sit at different distances from the hardware, and the distance is a trade: closer runs faster and costs more labour, further finishes sooner and prevents whole categories of error. There is also a claim in here that is easy to pass over and worth stopping on. Any algorithm can be converted from any reasonable computational model into any other — which is why a language choice is a practical decision rather than a question of what is computable. And the unit revisits Unit Two's concurrency distinction with a third term added, because the difference between sharing one machine and spanning several is not the same difference again. By the end you will be able to do five things. One: name the three kinds of model, and what each is built for. Two: say why a computer never runs your code. Three: state the trade between low and high-level languages. Four: tell concurrent, parallel and distributed apart. Five: say what a pointer reaches, and what an overflow costs.

Five entries, and the useful organising idea is that the three kinds have three different audiences. One is for machines, one is for people writing programs, and one is for thinking about algorithms without running anything at all.

The general idea.

CS 0171 The Computational Model

A system defining what an algorithm does and how to carry it out — which can be a physical device, a programming language, or a purely abstract construction.

Three kinds.

CS 0172 Three Kinds of Models

Hardware models built for machines, programming models built for people, and abstract models built for reasoning. Each is aimed at a different audience.

For the machine.

CS 0173 The Hardware Model

A processor's instruction set — the defined list of operations a chip can execute. It is built for hardware to implement rather than for anybody to read comfortably.

For people.

CS 0174 The Programming Model

A syntax of keywords, operators and punctuation designed for humans to read and write. Everything about its design is a concession to the reader.

And for thinking.

CS 0175 The Abstract Model

A model for reasoning rather than executing — used to devise algorithms and analyse them without any machine involved at all.

Two entries. What bridges the models, and then a claim worth pausing on — that any algorithm can move between any of these models, which makes a language choice practical rather than fundamental.

The bridge.

CS 0176 The Compiler and the Interpreter

Translating source written in a higher-level language into a form the machine can execute — because the machine cannot execute anything else.

And the claim.

CS 0177 The Church-Turing Thesis

An algorithm can be converted from any reasonable computational model into any other. So which language a thing is written in decides how hard it is to write, and never what can be computed.

Two entries naming one axis and what moving along it costs. There is no better end — there are two different bills, and which one you would rather pay depends on what you are building.

The axis.

CS 0179 The Level of Abstraction

How closely a language relates to the machine — low-level languages describing the hardware's own operations, high-level ones describing what the programmer means.

And the trade.

CS 0180 Performance or Productivity

Low-level programs usually execute faster and cost more labour. High-level programs are finished sooner and prevent whole categories of error from occurring at all.

Three entries, and the error entry in the middle is one people find genuinely surprising. Whatever anybody writes, it is not what the machine runs — and the layer directly above the metal makes that visible.

What runs.

CS 0181 Machine Code

A sequence of binary digits executed directly. It is the only computational model a computer can actually run, and everything else is a convenience above it.

And the error.

CS 0182 "The Computer Runs My Code"

A computer never executes source code. Every program written above the lowest level is translated down before anything happens — so what ran was never what was typed.

The layer directly above.

CS 0184 Assembly Language

A low-level language where each statement corresponds directly to one machine instruction — a readable form of the thing the processor actually does.

Four entries on ways of organising a program, and the useful thing to notice is the descent — each grows out of the one before it rather than replacing it, so they nest rather than compete.

The first.

CS 0186 Structured Programming

Building control flow from conditionals and loops rather than unrestricted jumps — a restriction that makes a program's behaviour possible to reason about.

The second.

CS 0187 Procedural Programming

Organising code into named procedures, each built for one task. It descends from the previous approach rather than replacing it.

The third.

CS 0188 Object-Oriented Programming

Organising code into objects holding both data and the procedures acting on it. Another descent — the procedures are still procedures, now bundled with what they operate on.

And the fourth.

CS 0189 Functional Programming

Writing algorithms as mathematical functions converting input to output. This one descends from a different line, which is why it feels unlike the other three.

One procedure, and it is the ground-level skill underneath everything else in the unit. Running an algorithm by hand, one line at a time, with every variable written down at every pass.

Watch a loop get traced.

CS 0190 Tracing a Loop to Its Floor

Executing an algorithm by hand, one step per line, tracking every variable through every pass. Nothing about it is clever — and it is how a program's actual behaviour becomes visible rather than assumed.

Five entries on a language that sits near the hardware, what that proximity grants, and what it costs. The fourth entry describes a failure with public consequences — a value outgrowing the space allotted to it.

The language.

CS 0193 The C Language

A procedural middle-level language giving programs low-level access to memory — the language sitting underneath operating systems.

What it grants.

CS 0194 The Pointer

A variable holding the memory address of another variable — the mechanism giving a program direct reach into memory rather than access only through names.

The budget.

CS 0195 The Data Type's Budget

A variable's type determines how much memory it occupies and which operators it accepts, and good practice chooses the smallest type the values will fit into.

And what happens when they do not.

CS 0196 The Overflow Lesson

A value exceeding its type's range overflows — and the entry cites a forecasting failure with public consequences, repaired by moving to a larger type. The budget is real and so are the consequences of misjudging it.

The build.

CS 0197 Compile, Link, Run

Compilation translates the source, linking collects and combines the compiled pieces, and then the result runs. Three stages, and errors surface differently in each.

Six entries on running things simultaneously. Hardware with several processors, then three terms that get used interchangeably and mean different things, and two models for how separate tasks coordinate.

The hardware.

CS 0201 The Core and the Multicore

A core is one processor inside a chip, and a multicore processor carries several. That is the prevailing shape of hardware now rather than an exotic arrangement.

The other processor.

CS 0202 The GPU

A massively parallel processor supplementing the main one — thousands of cores, each individually weaker, suited to work that divides into many identical pieces.

The technique.

CS 0203 Parallel Programming

Dividing a program's task into parts executing on multiple cores or machines at the same time. The division is the work — not every task divides cleanly.

Three terms.

CS 0204 Concurrent, Parallel, Distributed

Concurrent is broadest — tasks overlapping, on one processor or many. Parallel means genuinely simultaneous. Distributed means spanning separate machines. They nest rather than being synonyms.

The first coordination model.

CS 0205 The Shared Memory Model

Parallel tasks reading and writing one shared address space, with mechanisms needed to stop them interfering. Coordination becomes the hard part.

And the second.

CS 0206 The Message Passing Model

Separate processes communicating only by sending messages and never sharing memory. The interference problem disappears and a different set of problems arrives.

Two entries closing the material. Computers living inside products nobody thinks of as computers, and one newer language noted once — for keeping a language's strengths while removing a class of its failures.

Computers inside things.

CS 0209 The Embedded Computer

A computer inside a product not used as a computer — constrained in size and energy, and increasingly connected to a network.

And one language.

CS 0210 Rust, Noted Once

A newer middle-level language keeping efficiency, portability and modularity while adding guarantees about memory that the older one could not make.

One capstone, and it takes the shortest possible action — a single button press — and follows it through every layer the unit described, from the language a person wrote down to the digits the processor executed.

The capstone. A button, followed down.

CS 0215 One Press, All the Way Down

A single press on an embedded device travelling the whole territory of the unit — from a human-readable language, through translation, to the sequence of digits a processor actually runs.

Five things you can now do. You can name the three kinds of computational model and their audiences — one for machines, one for people writing, and one for thinking without running anything. You can say why a computer never runs the code anybody wrote, because everything above the lowest level is translated down before execution. You can state the trade along the abstraction axis: closer to hardware runs faster and costs more labour, further away finishes sooner and prevents whole classes of error. You can tell the three terms apart — concurrent as the broadest, parallel as genuinely simultaneous, distributed as spanning machines — and that they nest. And you can say what a pointer reaches and what an overflow costs, with a forecasting failure as the example of misjudging a budget.