The 3 Things Computers Actually Do
Joseph Flanigan
"Computers do 3 things" is the prompt I gave the AI Deep Seek. I was not surprised that the AI did not have a direct answer. I know the answer from years of experience. Computers do 3 things: add, compile, move data. The compile steps are source, syntax, semantics, intermediate form, semantics, syntax, target.
After dialog with the AI, I had the AI write this Blog using my knowledge as framework. The AI was able to do research to provide more details.
As a test I asked the AI to explain the mouse. It took a couple of passes to connect that every part of the computer has a computer that does 3 things in every component.
I reviewed the post material.
Deep Seek
Ask most computer science graduates what a computer does, and the standard line comes: “fetch, decode, execute” or “arithmetic, move, branch.”
Ask a compiler writer? Something else entirely.
Ask someone who has actually watched what happens from source code to running program — the answer becomes clear.
Computers do exactly three things.
Not ten. Not a hundred. Three.
Thing 1: They Add
At the rock bottom of every operation — every game rendered, every database queried, every neural network trained — lives the ALU (Arithmetic Logic Unit). And the ALU mostly just adds.
Subtraction? Addition with negation.
Multiplication? Repeated addition.
Division? Repeated subtraction.
Address calculation? Addition.
Array indexing? Addition plus addition.
Even logical operations (AND, OR, XOR) sit right next to the adder on the silicon.
What “add” includes:
• Integer arithmetic (add, subtract, multiply, divide)
• Floating-point operations
• Bitwise logic (AND, OR, XOR, NOT)
• Shifts and rotations
• Comparisons (which are just subtraction with a discarded result)
What “add” does NOT include:
• Any transformation that requires remembering previous state
• Any operation that restructures data
• Any translation between representations
Add is pure. Add is stateless. Add is the hammer.
Thing 2: They Compile
This is the operation nobody talks about — and it is everywhere.
By compile, the meaning is not “run GCC.” The meaning is: transform information from one representation to another through structured phases, with the ability to maintain state across invocations.
The key word is reentrant.
Converter vs. Compiler
| Converter | Compiler | |
|---|---|---|
| Static vs dynamic | Fixed transformation | Can be reentrant |
| State | Stateless (or fixed mapping) | Maintains internal state across invocations |
| Context awareness | None — same input always yields same output | Behavior can differ depending on previous inputs or external state |
| Example | ADC: 2.3V → always same 8‑bit value | Mouse DSP: compares current frame to previous frame to compute delta |
A converter is a pure function: f(x) = y
A compiler can be reentrant: f(x, state) → (y, new_state)
Where Compilation Happens (Everywhere)
Look closely at anything a computer does:
- Fetching an instruction — The CPU compiles a bit pattern (machine code) into micro-ops.
- Rendering a font — The system compiles a Unicode codepoint → glyph index → outline → rasterized pixels.
- Playing an MP3 — The decoder compiles a compressed bitstream → frequency coefficients → audio samples.
- Running JavaScript — The VM compiles source → AST → bytecode → machine code (sometimes multiple times).
- Querying SQL — The database compiles SQL → parse tree → query plan → row operations.
- Mouse movement — The microcontroller compiles pixel frames → delta values → HID report.
The pattern is always the same:
That is compilation. That is what computers spend most of the time doing — not adding, not moving, but transforming with memory of what came before.
Why Reentrancy Matters
A compiler that forgets everything between calls is useless.
• A TCP stack must remember sequence numbers across packets.
• An audio decoder must remember the previous sample for prediction.
• A mouse tracking motion must remember the previous frame to compute delta.
This is what separates compilation from mere conversion. An ADC (analog‑to‑digital converter) is static. Give the same voltage, get the same number. A motion‑tracking DSP is a compiler. Give the same pixel pattern, and its output depends entirely on what came before.
Thing 3: They Move Data Around
This one seems obvious until realizing how much of computing is just this. Load from RAM to register. Store from register to cache. Copy from disk to memory. Send from memory to network interface. Receive from network to buffer.
Modern computers are not compute-bound. They are data‑movement‑bound.
• CPU waits for cache (movement stalled).
• Program waits for disk (movement stalled).
• Database waits for network (movement stalled).
The entire field of high‑performance computing is, at the heart, the art of hiding how long it takes to move data.
What “move” includes:
• Load (memory → register)
• Store (register → memory)
• Copy (register → register)
• DMA transfers (device ↔ memory)
• Network sends and receives
• Cache line fills and evictions
What “move” does NOT include:
• Any transformation of the data (that is compile or add)
• Any stateful processing (that is compile)
Move is pure relocation. Move is latency. Move is the bottleneck.
The Hidden Triad
What makes this model powerful: everything a computer does fits into exactly one of these categories.
| If it is... | Then it is this |
| Calculating, comparing, shifting, masking | Add |
| Parsing, decoding, translating, encoding, optimizing, any stateful transformation |
Compile |
| Loading, storing, copying, sending, receiving | Move |
Take any computing task and decompose it. No fourth thing appears.
📌 Case Study: How a Mouse Works (The Full Pipeline)
Inside the mouse:
- LED illuminates surface → photodiodes detect light → analog voltages
- ADC converts voltage to pixel value → converter only (static, not a compiler)
- DSP stores previous frame → state saved
- DSP compares current frame to previous → Compile (reentrant)
- DSP computes delta‑X, delta‑Y → difference calculation = Add
- Microcontroller packs delta + button state into HID report → structuring = Compile
- USB controller serializes report → framing = Compile
- USB cable transmits bits → electrical movement = Move
Inside the computer:
- USB host controller receives bits → movement into buffer = Move
- HID driver parses report → unpacking = Compile
- OS extracts delta‑X, delta‑Y → no operation per se
- Window system adds delta to cursor position (
x += dx) → Add - Graphics stack compiles cursor position to pixels → transform = Compile
- Framebuffer moves pixels to display → memory → screen = Move
Every step is add, compile, or move. Nothing else.
Why This Framework Matters
The standard “fetch‑decode‑execute” model describes what the CPU does internally.
The add, compile, move model describes what the system does at every level.
Once compilation is seen as a primitive — on par with addition and movement — and the converter/compiler distinction is understood, confusion vanishes around:
- Why JIT compilers exist (they turn “compile” from a stage into a loop)
- Why data formats matter (they determine what “compile” must do)
- Why modern CPUs have hardware decoders (tiny compilers in silicon)
- Why GPUs are different (movement optimization over compilation)
- Why stateful parsing is hard (most textbooks teach parsing as conversion, not reentrant compilation)
Common Objections
“What about storing data on disk?”
Storage is just move to a slower medium, followed by compile (file system formatting, encoding) so the data can be found again.
“What about encryption?”
Encryption is compile — plaintext → ciphertext through a stateful algorithm, often with chaining modes (CBC) that require previous block state.
“What about random number generation?”
RNG is compile — internal state (seed or entropy pool) maintained and transformed into output numbers.
“What about the ADC in the mouse?”
The ADC is a converter, not a compiler. Static and stateless. It is the only component in the entire system that does not fit neatly into add/compile/move — because it is not computing. It is measuring. The computer begins after the ADC.
A Challenge
Next time while debugging, profiling, or designing a system, ask three questions:
- Am I adding? (Is this ALU work?)
- Am I compiling? (Am I transforming representation with state?)
- Am I moving? (Is this data transfer?)
If the answer is unclear, one of the three is missing.
And if a fourth operation that a computer performs is found — or an operation that is neither converter nor add nor compile nor move — then the model must evolve. But until then, the triad holds.
