Assembly (x86-64)

The CPU has sixteen slots to work in and billions of bytes to work from. The gap between those two speeds explains most of what optimised code is doing.

Assembly is not one language. Pinning down architecture, syntax and conventions now means every example for the rest of the course reads the same way.

No new ideas. Just you, a few short programs, and the question every assembly programmer answers a hundred times a day: what is in that register now?

Meet RAX through R15 by name. Their odd letters are a forty-year-old fossil, and two of them are not really general purpose at all.

One instruction accounts for roughly a third of all code your compiler emits. It is also badly named, and the name causes real bugs.

Swapping two registers is the first problem where the copy-not-move rule bites. Solve it the classic way, then meet the instruction that does it in one line.

RAX, EAX, AX and AL are not four registers. They are four differently sized windows onto the same 64 bits, and knowing that turns confusing disassembly into obvious code.

Writing to an 8-bit or 16-bit register leaves the rest alone. Writing to a 32-bit register wipes the top half. This asymmetry is real, deliberate, and everywhere in compiled code.

Everything from this module, in anger. Shuffle values between registers, keep track of which copy is which, and stay on the right side of the zero-extension rule.

No types, no names, no structure. Just numbered boxes holding one byte each, from zero to enormous. Everything else is something a language built on top.

One pair of square brackets is the difference between a number and a place. Get this wrong and your program reads an address as data, which is a classic and confusing bug.

Writing to memory is a mirror image of reading from it, except for one case where the CPU genuinely cannot guess how many bytes you meant.

One bracket expression can multiply, add and offset, all for free, in the same instruction that does the load. This is how array indexing happens in a single line.

One instruction uses square brackets and then deliberately does not read memory. It is the answer to "where is it?" rather than "what is in it?", and compilers love it for a second reason.

Loads, stores, sizes, indexed addresses and LEA, all mixed together. Plus the byte-ordering rule that explains why memory sometimes looks backwards.

Two instructions, one shape, and one habit that catches everyone coming from a high-level language: the destination is also an input.

Three one-operand instructions. Two of them look like shorthand for ADD and SUB but differ in one specific, occasionally important way.

There is no minus sign in a register, only 64 bits. Two's complement is the trick that makes subtraction and addition the same circuit, and it explains a whole family of real bugs.

IMUL looks like a normal two-operand instruction, and mostly is. The complication is that multiplying two 64-bit numbers can produce a 128-bit answer.

Division uses a fixed register pair, needs a setup instruction, returns two answers at once, and is the only arithmetic instruction that can kill your program outright.

A given starting value, a target, and a budget of instructions. Every challenge in this lesson has more than one right answer, and finding the short one is the fun part.

The CPU has no memory of what it just did, except for four single bits it sets automatically after every calculation. Those bits are where every if statement comes from.

The two flags you will read most often, plus the idiom every compiler uses to ask "is this value zero?" without changing anything.

The comparison instruction does not compute "equal" or "greater". It subtracts, keeps the flags, and discards the answer, and every comparison in every language is built on that.

Two flags that both mean "it did not fit", for two different meanings of "fit". The CPU sets both every time, because it does not know whether you meant signed or unsigned.

Given a program, what do the flags say when it stops? And given a set of flags, what could have caused them?

A label is a name for a place in the program. JMP sends the instruction pointer there, and that is the entire machinery behind every control structure you have ever used.

Combine a comparison with a jump that reads the flags, and you have every decision a computer can make. This is the lesson where the whole course clicks together.

Four more jumps cover every ordering comparison. Their names read naturally as long as you remember which operand the comparison was about.

x86 has two complete sets of ordering jumps, one for signed values and one for unsigned. Picking the wrong set is a silent, security-relevant bug.

Take a C if/else apart and put it back together in assembly, then meet the trick compilers use to avoid branching at all when the branch is unpredictable.

Follow the instruction pointer through branching code and predict where it lands. This is the exact skill you use when reading a disassembly or stepping through a debugger.

Every loop you have ever written has the same four parts. In assembly they stop being syntax and become four separate instructions you have to place yourself.

Compilers turn your counting-up loop into a counting-down loop whenever they can, and the reason is one instruction you no longer need.

Combine a loop counter with a scaled memory operand and you can visit every element of an array. This is what the overwhelming majority of real loops actually do.

Break and continue look like special keywords in a high-level language. In assembly they are just two more jumps, aimed at two different labels.

Trace loops, count iterations, spot the infinite one, and write a nested loop. Everything from this module, and nothing new.

It is a region of ordinary memory and one register pointing into it. Everything else you have heard about the stack follows from those two facts.

Two instructions, each shorthand for two others. Once you can expand them by hand, the stack stops being mysterious.

A function call is a jump that leaves a note saying where to come back to. The note goes on the stack, and everything about functions follows from that.

Recursion needs no new instructions. Watch the stack grow with each call and shrink on the way back, and the whole idea stops being mysterious.

Given a stack, work out what RET will do. Given an imbalance, work out where it breaks. This is the skill that makes crash dumps readable.

The hardware has no idea what a function argument is. Passing one works because everybody agreed, in advance, which registers to use.

Sixteen registers, shared by every function in the program. The convention divides them in two, and knowing which half is which explains the shape of every compiled function.

A local variable is a fixed distance from a register. Once you can read the frame diagram, C's stack behaviour and a whole category of crash become obvious.

Arguments in, answer out, registers preserved. Write functions that obey the convention, including one that calls another.

A register is not a number, it is sixty-four switches. Learning to see the switches is what makes the next five lessons feel easy instead of arbitrary.

Four instructions that work on every bit independently, in parallel, in one cycle. Each has one job, and the jobs are worth learning as verbs.

A mask is a pattern that says which bits you mean. Combine one with the right operation and you can test, set, clear or toggle any individual bit.

Sliding every bit one position left doubles a number. That coincidence makes shifts the cheapest multiplication and division there is, and the distinction between the two right shifts matters.

A small collection of bit patterns that appear in production code everywhere, plus honest advice about when reaching for them is a bad idea.

Masks, shifts, flags and packed fields. Extract a value from the middle of a word, build one, and count bits.

There is no array type in the hardware. There is a starting address and a distance between elements, and every array behaviour you know follows from those two numbers.

A string is an array of bytes with a zero on the end. That single design decision explains an entire genre of security vulnerability.

A struct is a base address and a fixed offset per field. Field names vanish at compile time, and the padding the compiler inserts explains why struct sizes surprise people.

There is no print instruction. Every file read, every byte on screen and every network packet is a program asking the kernel for a favour, and here is exactly how it asks.

Arrays, strings, structs and one real program that prints something. Everything this module covered, applied.

Put a C function and its compiled output side by side and read across. Once the mapping clicks, disassembly stops being a foreign language.

Recognise a branch, a loop and an early return on sight. These three shapes account for most of the control flow in any program you will ever disassemble.

You have a simulator, a step button and every register on screen. That is more information than most debugging sessions give you, and the method for using it is worth making explicit.

Segmentation fault, divide error, stack overflow, jumped-to-nowhere. Four messages you have seen for years, and now you can read each one as a specific machine event.

Programs you did not write, questions you must answer before running them. Predict, then check, then explain the gap.

One complete program that uses something from every module, walked through end to end. Then you write the last piece yourself.