Machine code and assembly — what actually runs

WHAT is machine code?

WHY two names for the same thing? Binary 10110000 01100001 is impossible for humans to read. Assembly gives it a mnemonic (MOV AL, 0x61). Same instruction, different representation — like writing the number "thirteen" vs "13" vs "1101".

HOW an instruction is built (derive it from scratch)

A CPU can't read English. So we must encode "add register 2 and register 3, store in register 1" as bits. Let's design such an encoding to see there is no magic.

Step 1 — What must the bits tell the CPU?

• WHICH operation? (add / sub / load / jump…) → call this the opcode.
• WHICH data to use? → the operands (registers, or a constant, or a memory address).

Why this step? Every instruction is just "do X to Y" — opcode = X, operands = Y.

Step 2 — Allocate bits. Suppose our toy CPU has:

• 8 possible operations → we need $\lceil \log_2 8 \rceil = 3$ bits for the opcode.
• 4 registers → $\lceil \log_2 4 \rceil = 2$ bits to name each register.

Why $\log_2$? With $n$ bits you can label $2^n$ distinct things, so to label $k$ things you need $n \ge \log_2 k$.

Step 3 — Lay out one 9-bit instruction ADD R1, R2, R3:

$\underbrace{010}_{\text{opcode=ADD}}\;\underbrace{01}_{\text{dest }R1}\;\underbrace{10}_{\text{src }R2}\;\underbrace{11}_{\text{src }R3}$

That single binary word 010 01 10 11 is the machine code. The assembler produced it from the text ADD R1, R2, R3. The CPU reads it and the wiring does the addition.

HOW the CPU actually runs it — the fetch–decode–execute cycle

Why a PC? Programs are just lists in memory. Something must remember "where are we?" — that's the PC. A jump instruction simply writes a new value into the PC, which is how if/loops/functions exist at the bottom level.

The translation ladder (WHY assembly sits where it does)

C source                  Python source
   │  compiler               │  interpreter (CPython)
   ▼                         ▼
Assembly (MOV, ADD, JMP)   Python bytecode  ──► VM loop runs each
   │  assembler             (runs on a virtual machine, not the CPU directly)
   ▼                              │
Machine code (raw bytes)   ◄──────┘ (the VM itself is machine code)
   │  CPU hardware
   ▼
Electrons / logic gates   ← physics

• Compiler (C, Rust, etc.): high-level language → assembly, ahead of time (does the hard creative work: loops, types, optimization).
• Interpreter (standard/CPython): does not turn your Python into native assembly. It first compiles your .py to portable bytecode, then a loop inside the interpreter (the virtual machine) executes each bytecode op. The interpreter program is itself machine code that the CPU runs.
• Assembler: assembly → machine code. It is not just an opcode lookup — it also does label resolution (turning ADDR1 into a real address), relocation (so code can be placed anywhere in memory), macro expansion, and directive handling.
• CPU: machine code → actions (hardware).

Worked examples

Common mistakes (steel-manned)

Active recall

Connections

• Binary and Number Systems — opcodes/operands are just binary numbers; $\lceil\log_2 k\rceil$ comes from here.
• The CPU and Registers — registers are the operands instructions act on.
• Memory and Addressing — the PC holds a memory address; programs live in memory; relocation fixes addresses.
• Compilers and Interpreters — produce/execute the machine code that runs; bytecode vs native code.
• Logic Gates and Boolean Algebra — execute step is physically done by gates.
• Control Flow — if/loops compile down to conditional jumps editing the PC.

Concept Map

Hinglish (regional understanding)