From Your Code to the Machine

Follow one line of C all the way down: compiler, assembly, assembler, bytes. Once you have seen the trip, assembly stops feeling like a separate world.

Take the most boring line of code imaginable:

long total = 10 + 32;

When you build that program, a compiler reads it and writes out assembly. Here is one thing it might produce:

mov rax, 42
mov [total], rax

("Might", not "must". Different compilers and optimisation levels emit different instructions for the same source, and you will see that for yourself in Module 12. What matters here is the shape.)

We used long rather than int so the value is 64 bits, the same width as RAX. Module 2 explains why narrower types use different register names.

Two things worth noticing immediately.

First, the addition is gone. The compiler could see that 10 + 32 never changes, so it did the arithmetic itself and emitted the answer. That is called constant folding, and it is your first glimpse of why compiled code rarely looks like the source.

Second, total became a place in memory. The name existed only for you.

Multiple choice

The compiler turned long total = 10 + 32; into mov rax, 42. Where did the addition go?

AThe compiler computed it at build time, because both values were known
BThe CPU performs it silently as part of the mov instruction
CIt was moved into a separate instruction further down the program
DIt is stored in the executable and performed when the program loads

So the full journey looks like this:

  long total = 10 + 32;     ← what you write
          │
     compiler
          ▼
  mov rax, 42               ← assembly (readable)
          │
     assembler
          ▼
  48 C7 C0 2A 00 00 00      ← machine code (bytes)
          │
      the CPU
          ▼
      it happens

Python and JavaScript take a detour through an interpreter or a just-in-time compiler, but they land in exactly the same place. There is no language that escapes the bottom of this diagram.

One more job sits between the assembler and a runnable program: the linker, which stitches your code together with the library code it calls. We will meet it again in Module 11.

Multiple choice

Put the four stages in the order a C program actually passes through them.

Asource code → compiler → assembly → assembler → machine code
Bsource code → assembler → assembly → compiler → machine code
Cassembly → source code → compiler → machine code
Dsource code → compiler → machine code → assembly

You can watch this happen on your own machine. With GCC or Clang installed:

gcc -S -O0 -masm=intel program.c

-S means "stop after producing assembly", and -masm=intel asks for the syntax style this course uses. You get a .s file full of exactly the kind of instructions you are about to learn.

A professional habit worth forming early: when you cannot explain why some code is slow, or why a compiler optimisation did or did not fire, look at the assembly. It is the only answer that cannot be wrong. Online tools like Compiler Explorer put source and assembly side by side and will become one of your favourite toys by the end of this course.

Fill in the blank

The program that translates a high-level language into assembly is called a ___.

Multiple choice

Why does compiled assembly so often look nothing like the source it came from?

AThe compiler is free to rewrite anything, as long as the observable behaviour matches
BAssembly cannot express the same operations, so the compiler approximates them
CThe compiler shuffles instructions randomly to defeat reverse engineering
DSource code order is preserved, but the instruction names are different

Recap 🧠

A compiler turns high-level source into assembly. An assembler turns assembly into machine-code bytes. A linker joins the pieces into a runnable program.
Every language lands at machine code eventually. Interpreted languages just take a longer road.
Compiled assembly often looks nothing like the source: the compiler only has to preserve observable behaviour, so it folds constants, deletes dead work and reorders freely.
gcc -S -masm=intel shows you the assembly for your own C code, and reading it is the most reliable way to answer "why is this slow?".

Next lesson: what the CPU is doing between instructions. It is simpler than you would guess, and it repeats forever.

Take the most boring line of code imaginable:

long total = 10 + 32;

When you build that program, a compiler reads it and writes out assembly. Here is one thing it might produce:

mov rax, 42
mov [total], rax

("Might", not "must". Different compilers and optimisation levels emit different instructions for the same source, and you will see that for yourself in Module 12. What matters here is the shape.)

We used long rather than int so the value is 64 bits, the same width as RAX. Module 2 explains why narrower types use different register names.

Two things worth noticing immediately.

Second, total became a place in memory. The name existed only for you.

long total = 10 + 32; ← what you write │ compiler ▼ mov rax, 42 ← assembly (readable) │ assembler ▼ 48 C7 C0 2A 00 00 00 ← machine code (bytes) │ the CPU ▼ it happens