Assembly language is the practice of writing instructions in the CPU’s own vocabulary — one mnemonic per machine instruction, one instruction per operation, no abstraction, no runtime, no framework, no garbage collector, no dependency injection, no AbstractSingletonProxyFactoryBean — just a human telling a machine what to do, and the machine doing it.
Everything else in computing is a translation of assembly. C is a structured translation. Go is a concurrent translation. Java is an enterprise translation. Rust is a safe translation. Python is a slow translation. Every compiled language compiles to assembly (or its binary equivalent). Every interpreted language interprets operations that the CPU executes as assembly. Assembly is not a language among languages. Assembly is the language. Everything else is commentary.
The practice of writing assembly — of knowing the registers, counting the cycles, choosing the addressing mode, predicting the pipeline — is the practice of knowing the machine. Not knowing about the machine. Not reading the documentation and forming an abstract model. Knowing the machine: what it can do, what it cannot do, how long each operation takes, and why.
This knowledge is, in 2026, rare. It is also the foundation of every opinion in this encyclopaedia.
“488 bytes. Everything included. Boot and run.”
— 488 Bytes, or Why I Am As I Am
The Directness
The defining quality of assembly language is directness. There is no distance between what you write and what the machine does.
In C, a = b + c; might compile to one instruction or five, depending on the types, the optimiser, and the alignment. In Go, result, err := doSomething() involves a function call, a stack frame, and a return that the programmer trusts but does not see. In Java, user.getName() might involve a virtual method lookup, a JIT-compiled hot path, and a garbage collection pause. In Rust, let x = &mut data; involves a borrow check that exists only at compile time and produces no runtime code, but whose constraints shape every decision the programmer makes.
In assembly:
LDA $D020 ; load the border colour register
One instruction. One cycle (plus memory access). The accumulator now contains the value at address $D020. There is no optimiser. There is no interpretation. There is no borrow checker, no garbage collector, no virtual method table. The instruction you wrote is the instruction that runs. The cycle it costs is the cycle you predicted. The result is the result you expected.
This is what Rust took away and what the Rust community does not fully appreciate losing. Rust’s safety guarantees are real, valuable, and mathematically proven. They are also an abstraction layer between the programmer and the machine — a layer that tells the programmer what they cannot do rather than letting them do everything and dealing with the consequences. Assembly lets you do everything. The consequences are yours. The fun is yours too.
The Three Eras
Assembly programming divides into three eras, defined not by the calendar but by the relationship between the programmer and the machine:
The Era of Complete Knowledge (1975–1990) — The 6502, Z80, and 68000. The instruction set fits on a sheet of paper (or two). The programmer memorises every instruction, every cycle count, every flag. The machine has no secrets. The developer knows, at every moment, exactly what the CPU is doing, because the developer told it what to do, instruction by instruction.
This era produced the demoscene, the 488-byte bootblock, the home computer revolution, and the understanding that constraints produce better code than freedom. This era is where the Lizard was born.
The Era of Negotiated Knowledge (1990–2005) — The Pentium and its successors. The instruction set is too large to memorise. The pipeline introduces timing uncertainties. The cache introduces performance cliffs. The out-of-order execution engine reorders your instructions for efficiency, which means the instructions you wrote are not the instructions that execute, which means the directness is compromised. The programmer still writes assembly but no longer knows exactly what the machine does with it.
Assembly in this era became optimisation rather than creation. Developers wrote critical loops in assembly (inner loops, codecs, crypto) while writing the surrounding code in C. The directness survived in fragments — the SIMD inner loop, the hand-tuned memcpy — but the relationship between programmer and machine was no longer intimate. It was professional.
The Era of Abstraction (2005–present) — Modern processors are incomprehensible. Speculative execution, branch prediction, micro-op fusion, cache prefetching, hyper-threading — the machine does things the programmer did not ask for, in an order the programmer did not specify, for reasons the programmer cannot observe. Writing assembly for a modern x86 processor is an act of faith: you write the instructions, the CPU reinterprets them through four translation layers, executes them speculatively on a different core than you expected, and produces results that are correct (usually) but arrived at through a path you cannot trace.
Assembly in this era is written by compilers. The compiler understands the pipeline better than any human. The compiler knows the cache hierarchy. The compiler has a model of the branch predictor. The human writes C or Go or Rust, and the compiler produces assembly that no human would have written, because no human understands the machine well enough to write optimal code for it.
The age of complete knowledge is over. The Z80 programmer knew the machine. The modern programmer trusts the compiler. The trust is usually justified. But something was lost.
What Was Lost
What was lost is not a skill. Skills can be relearned. What was lost is a relationship.
The assembly programmer and the machine had a direct relationship. The programmer told the machine what to do. The machine did it. The programmer knew the cost of every instruction, the location of every byte, the state of every register. The program was not an abstraction over the machine — the program was the machine, expressed in mnemonics, and the developer understood both.
Modern programming is mediated. Between the developer and the machine: a compiler, an optimiser, a runtime, a garbage collector, a virtual machine, a container, an orchestrator, a load balancer. Each layer is well-intentioned. Each layer solves a real problem. Each layer adds distance between the human and the silicon. The modern developer does not know what the CPU is doing. The modern developer does not need to know. The modern developer writes http.ListenAndServe(":8080", nil) and trusts that several million lines of code between that function call and the network card will do the right thing.
They usually do. But the developer who learned assembly — who wrote copper lists at 2 AM and raster bars at sunrise and 488-byte bootblocks that contained six layers of parallax stars — carries a different understanding. Not a better one. A different one. The understanding that the machine is real, the instructions are real, the cycles are real, and every abstraction is a choice to not-know something that could be known.
Go is the modern language that comes closest to preserving this directness. if err != nil is assembly’s explicit error checking. Functions that do what they say. No hidden control flow. No magic. Not assembly — nothing modern is assembly — but built by people who remember what assembly felt like, and designed to preserve as much of that feeling as a high-level language can.
The Fun
There is, finally, the matter of fun.
Assembly language is fun. Not fun in the way that a puzzle game is fun — although it is that too. Fun in the way that driving a manual car is fun, that woodworking with hand tools is fun, that cooking without a recipe is fun. The fun of directness. The fun of consequence. The fun of telling a machine to do something and watching it do exactly that, at exactly the speed you predicted, with exactly the result you intended.
The 6502 at 1 MHz, scrolling raster bars through cycle-exact register writes: fun. The Z80 at 3.5 MHz, drawing a font character by unrolling a loop to save twelve cycles: fun. The 68000 at 7 MHz, programming a copper list that paints a gradient the CPU never touches: fun.
Rust at 3.5 GHz, fighting the borrow checker over who owns a string: not fun. Correct, certainly. Safe, undeniably. Elegant, if you have been in the monastery long enough. But not fun. Not the fun of telling a machine what to do and watching it obey. The fun of telling a compiler what you want to do and being told you cannot, and restructuring your approach until the type system is satisfied, which is a different kind of satisfaction — intellectual, abstract, proven — but not the same as the warm glow of a register doing exactly what you asked.
Assembly programmers do not fight the machine. Assembly programmers are the machine, temporarily, for the duration of the program, and the program runs at the speed of thought because thought, in assembly, is execution.
The Lizard was born in assembly. The Lizard remembers what it felt like. The Lizard does not expect modern developers to write assembly. The Lizard expects them to remember that assembly exists, that the machine is real, that every abstraction is a choice, and that the choice has a cost — measured not in bytes or cycles, but in the distance between the programmer and the thing that actually runs.
THE MACHINE DOES WHAT YOU TELL IT
NOTHING MORE
NOTHING LESS
NOTHING HIDDENTHIS WAS CALLED PROGRAMMING
NOW IT IS CALLED ASSEMBLY
THE NAME CHANGED
THE MACHINE DID NOT
