Three Levels of the Same Program

When you write C++, you are writing in a language designed for humans. The processor inside your computer does not understand C++ at all. It understands only machine code: long sequences of numbers that encode tiny, primitive operations like "add these two numbers" or "copy this value from here to there".

Between the C++ you write and the machine code the CPU runs sits a third thing: assembly language. Assembly is a human-readable spelling of machine code. Every assembly instruction corresponds, almost one-to-one, to a single machine instruction. It is the lowest level you can realistically read.

Think of it as three views of the same program:

C++ source            ->   assembly             ->   machine code
(what you write)           (what you can read)       (what the CPU runs)

return a + b;              add eax, edx              01 d0

The C++ is concise and expresses intent. The machine code is what actually executes. Assembly is the bridge: it shows you, in words and short names, exactly what the CPU was told to do.

What Assembly Actually Looks Like

Here is a small C++ function:

int add(int a, int b)
{
    return a + b;
}

And here is the assembly the compiler produces for it (with optimizations turned on):

add(int, int):
    lea eax, [rdi+rsi]
    ret

Two instructions. The first computes the sum of the two arguments and places it where return values go. The second hands control back to whoever called the function. You do not need to understand every detail yet, and the short names like eax, rdi, and rsi are registers, tiny storage slots inside the CPU. The very next lesson is a quick vocabulary that defines registers and the other words you will keep seeing, so do not worry if those names mean nothing right now. The point is that this is readable: it is short, it is concrete, and by the end of this course you will read listings like this fluently.

Why Would a C++ Programmer Read Assembly?

You can write excellent C++ for years without ever looking at assembly. So why learn to read it?

To understand what your code really costs

C++ is famous for its "zero-overhead" abstractions, but "zero-overhead" is a claim you can actually check. Does that range-based for loop compile to the same thing as a hand-written index loop? Did the compiler really inline that tiny accessor, or is it paying for a function call every time? Reading the assembly turns these questions from guesses into facts.

To trust, and to verify, the optimizer

Modern compilers are extraordinary optimizers. They fold constants, eliminate dead code, and rewrite loops. Sometimes they optimize away code you thought was important, and sometimes they fail to optimize code you assumed they would. The only way to know for certain is to read what came out the other end.

To debug the truly strange bugs

When a debugger shows "optimized out" for a variable, or a crash lands in the middle of a function with no obvious cause, the source code is no longer enough. The assembly is the ground truth of what the machine is doing.

To understand undefined behavior

Many of C++'s sharpest edges, like signed integer overflow or reading uninitialized memory, are "undefined behavior". The compiler is allowed to assume they never happen and optimize accordingly. Reading assembly is how you see the sometimes surprising consequences of that assumption.

Assembly Is Specific to a Machine

There is one important catch. Unlike C++, which is portable across machines, assembly is tied to a specific instruction set architecture (ISA). The instructions, the register names, and the rules all depend on which family of processor you are targeting.

The two architectures you are most likely to meet today are:

  • x86-64 (also called AMD64 or x64), used by most desktops, laptops, and servers.
  • ARM64 (also called AArch64), used by phones, tablets, and Apple Silicon Macs.

The same C++ produces completely different assembly on each. This course teaches x86-64, because it is the most widely documented target and the one you will see most often when reading other people's examples, compiler explorer links, and performance articles. Everything you learn about how to read assembly transfers to other architectures even though the specific instructions differ.

A Note on Mnemonics

Assembly instructions are written using short names called mnemonics. They look cryptic at first but are just abbreviations:

Mnemonic Short for Roughly means
mov move copy a value from one place to another
add add add two values
sub subtract subtract one value from another
lea load effective address compute an address (often used for arithmetic)
ret return return from a function
call call call a function

You will meet each of these properly in later chapters. For now, notice that they read almost like English once you know the abbreviation. Learning assembly is far more about learning a small, consistent vocabulary than about memorising anything difficult.

What This Course Will and Will Not Do

This is a course about reading assembly, not writing it. You will not be asked to hand-write assembly programs. Instead, you will learn to look at the assembly your C++ compiles into and understand it: what each instruction does, how your functions and loops and data structures map onto it, and what the optimizer changed along the way.

Throughout the course you will be able to take a piece of C++, compile it, and view the generated assembly right here in the editor, so you can connect cause and effect for yourself.

Key Takeaways

  • Machine code is what the CPU runs; assembly is its human-readable form; C++ is the high-level language you write.
  • Each assembly instruction maps almost one-to-one to a machine instruction.
  • Reading assembly lets you see what your code costs, verify the optimizer, debug hard problems, and understand undefined behavior.
  • Assembly is architecture-specific. This course targets x86-64, the most common and best-documented architecture.
  • Instructions are written as short mnemonics like mov, add, and ret.