What assembly language is and why it matters

Every program a processor runs is a stream of bytes, called machine code. Assembly language is the human-readable spelling of those bytes: one line names one instruction, and an assembler translates each name into the opcode it stands for. Reading those names matters when a compiler’s output has to be checked, when a crash dump arrives without any source, when a loop runs slower than it should, when a security hardening claim must be verified, or when a bootloader or a driver has no higher-level language to hide inside.

This track teaches assembly for the three instruction set architectures that run most of the computing happening today: x86-64 on PCs and servers, AArch64 on phones and Apple silicon, and RISC-V on open and emerging hardware. Every program on every page is assembled, linked and run on a pinned toolchain, and the recording of that run — the exact command, the output and the exit status — is saved beside the lesson.

From text to bytes a processor can run

Open the lesson’s AArch64 program first: three lines of text in aarch64_exit42.s. mov w0, #42 puts the number 42 into register w0, ret returns to whoever called the function, and the label _main names the entry point the linker looks for on macOS. Each line is one instruction, and the three together are the function the processor runs.

The assembly languageassembly language: A human-readable spelling of a processor's instructions, one line per instruction, written to the rules of a single ISA. An assembler turns the text into the matching bytes; a program for one ISA does not run on another. is this human-readable spelling of a processor’s instructions, and the assemblerassembler: A program that reads assembly-language text and writes the matching bytes to an object file, with any labels, constants and directives the source used. clang, nasm and GNU as are three widely used assemblers. is the program that turns that text into the matching bytes. For the AArch64 program here, Apple’s clang acts as both: it assembles the three lines and links them into a Mach-O executable with one command.

The bytes themselves are machine codemachine code: The stream of bytes a processor really reads and runs, written to the rules of an ISA. Assembly language is a human-readable spelling of the same bytes; a disassembler reads the bytes and prints the spelling back., the only form the processor really reads. The disassemblerdisassembler: A program that reads the bytes of a compiled binary and prints the assembly instructions they encode, so a build with no source can still be read. otool, objdump and llvm-objdump are three widely used disassemblers. otool reads those bytes back and prints the same two instructions, so the source and the binary carry the same information in two different forms. A few bits inside each AArch64 instruction, together with the pattern of neighbouring bits, tell the processor which operation to run; that selector is the opcodeopcode: The group of bits inside an instruction that tells the processor which operation to run, with the remaining bits of the instruction selecting registers, immediates and modes. The ISA fixes where each opcode sits and what it means.. In Mach-O here, the encoding of mov w0, #42 writes 42 directly into w0 and ret is a single four-byte instruction, so the whole .text section comes out to eight bytes.

Step through the chain from source to a running program; then the recording below shows the same eight bytes and the exit status 42:

"""Builds and runs the AArch64 exit42 program natively on Apple silicon, then shows the bytes a Linux x86-64 and
RISC-V assembler would produce for the same idea.

AArch64 is the native ISA of Apple silicon Macs, so Apple clang 21 assembles the .s file, ld links it to a Mach-O
executable, the shell runs it and echo $? reads its exit status: 42, in full. The x86-64 and RISC-V versions make a
Linux system call (exit) that the macOS kernel does not understand, so the session assembles them to object files with
the matching clang target and reads the bytes with llvm-objdump. No foreign code runs.
"""

import sys
import pathlib

sys.path.insert(0, str(pathlib.Path(__file__).parent / "sessions"))
import session  # noqa: E402

# Each line is one /bin/sh call, so ./prog and echo must stay on the same line to share $?.
session.run(
    """
# AArch64 (Apple silicon) assembles, links and runs natively. The shell's exit status is echoed back.
clang -o aarch64_exit42 aarch64_exit42.s
./aarch64_exit42; echo "aarch64 exit=$?"

# Read the three instructions of the executable with Apple's otool, Mach-O's disassembler.
otool -tv aarch64_exit42

# x86-64 (Linux). Assemble to an ELF object with the Homebrew LLVM 23 driver, then read its bytes.
# macOS cannot run the program: its kernel does not know the Linux exit system call.
/opt/homebrew/opt/llvm/bin/clang -c -target x86_64-linux-gnu x86_64_exit42.s -o x86_64_exit42.o
/opt/homebrew/opt/llvm/bin/llvm-objdump -d --no-print-imm-hex -M intel x86_64_exit42.o

# RISC-V (Linux). Same route: assemble to an ELF object, read its bytes with llvm-objdump.
/opt/homebrew/opt/llvm/bin/clang -c -target riscv64-linux-gnu riscv_exit42.s -o riscv_exit42.o
/opt/homebrew/opt/llvm/bin/llvm-objdump -d --no-print-imm-hex riscv_exit42.o
"""
)

# AArch64 (Apple silicon) assembles, links and runs natively. The shell's exit status is echoed back.
$ clang -o aarch64_exit42 aarch64_exit42.s
$ ./aarch64_exit42; echo "aarch64 exit=$?"
aarch64 exit=42

# Read the three instructions of the executable with Apple's otool, Mach-O's disassembler.
$ otool -tv aarch64_exit42
aarch64_exit42:
(__TEXT,__text) section
_main:
00000001000002d8	mov	w0, #0x2a
00000001000002dc	ret

# x86-64 (Linux). Assemble to an ELF object with the Homebrew LLVM 23 driver, then read its bytes.
# macOS cannot run the program: its kernel does not know the Linux exit system call.
$ /opt/homebrew/opt/llvm/bin/clang -c -target x86_64-linux-gnu x86_64_exit42.s -o x86_64_exit42.o
$ /opt/homebrew/opt/llvm/bin/llvm-objdump -d --no-print-imm-hex -M intel x86_64_exit42.o

x86_64_exit42.o:	file format elf64-x86-64

Disassembly of section .text:

0000000000000000 <_start>:
       0: b8 3c 00 00 00               	mov	eax, 60
       5: bf 2a 00 00 00               	mov	edi, 42
       a: 0f 05                        	syscall

# RISC-V (Linux). Same route: assemble to an ELF object, read its bytes with llvm-objdump.
$ /opt/homebrew/opt/llvm/bin/clang -c -target riscv64-linux-gnu riscv_exit42.s -o riscv_exit42.o
$ /opt/homebrew/opt/llvm/bin/llvm-objdump -d --no-print-imm-hex riscv_exit42.o

riscv_exit42.o:	file format elf64-littleriscv

Disassembly of section .text:

0000000000000000 <_start>:
       0: 05d00893     	li	a7, 93
       4: 02a00513     	li	a0, 42
       8: 00000073     	ecall

The build command, clang -o aarch64_exit42 aarch64_exit42.s, assembles and links in one step; ./aarch64_exit42; echo "aarch64 exit=$?" runs the resulting executable and prints aarch64 exit=42. The shell has read a status that two instructions set. The lower part of the recording shows the x86-64 and RISC-V versions of the same idea as bytes, which the next section looks at side by side.

The same idea in three ISAs

The three programs in the recording above do the same thing on three different processors: they place 42 somewhere the operating system reads and ask it to end the process. The difference is in which register holds the status, which instruction asks the operating system to end the process and what the resulting bytes look like.

An instruction set architectureinstruction set architecture: The contract between software and a processor: the registers a program may name, the instructions that act on them, how those instructions are encoded as bytes and the rules for memory, interrupts and privilege. x86-64, AArch64 and RISC-V are three ISAs. (ISA) is the contract between the software a programmer writes and the processor that runs it: the registers available to a program, the instructions that act on them, the way those instructions are encoded as bytes, and the rules for memory, interrupts and privilege. x86-64 is the ISA of today’s PCs and servers; Intel’s SDM and AMD’s APM are its two primary manuals. AArch64 is the 64-bit mode of Arm’s A-profile processors (Arm ARM DDI 0487 and the A64 ISA DDI 0602), used by every modern smartphone, every tablet and every Apple silicon Mac. RISC-V is a newer, open ISA (the RISC-V ratified specification library), common in embedded and research work and growing in India’s own Shakti and Vega chips and in Western server and GPU designs.

Three different ISAs, three different sets of registers, three different sets of bytes. The exit path in the recording above shows what that looks like for one small program:

• x86-64 Linux uses eax and edi and the syscall instruction. The three bytes behind syscall are 0f 05, and the two moves that load 60 (the number for exit) and 42 take five bytes each: b8 3c 00 00 00 and bf 2a 00 00 00. Twelve bytes together.
• RISC-V Linux uses a7 and a0 and the ecall instruction. Each instruction is four bytes wide: 05d00893 is li a7, 93, 02a00513 is li a0, 42 and 00000073 is ecall. Twelve bytes together as well.
• AArch64 (Apple silicon) returns 42 from _main with mov w0, #42 and ret, eight bytes. The C runtime that called _main passes w0 on to the operating system, so no svc or syscall is needed in the function itself.

A later lesson of this module writes each of the three programs in full and shows how each one ends. This section is about seeing that assembly is a family of languages, one per ISA, with the same underlying ideas, and that an engineer reading more than one of them meets most of the hardware they will ever work on.

Why reading assembly still matters

A high-level language usually hides the instructions a processor runs, so asking why anyone should still read assembly is a fair question. Six answers come up often in a working engineer’s life.

Compiler output. Compilers rearrange, inline, specialise and vectorise code enough that the shortest route to knowing what runs is to read the assembly they wrote. The same C function below becomes a single instruction on each of the three ISAs:

"""Shows what one C function looks like as assembly on each of the three ISAs the track teaches.

Homebrew LLVM 23 holds every target the track uses, so clang -S -O2 writes the assembly text for the host (AArch64)
and for the two cross targets (x86-64 and RISC-V) without running anything. For each ISA the driver prints the four
lines of the function: the label, its one add instruction, and the return. The lesson quotes those lines directly.
"""

import sys
import pathlib

sys.path.insert(0, str(pathlib.Path(__file__).parent / "sessions"))
import session  # noqa: E402

# sed prints every line from "add:" to the matching .cfi_endproc, which is the whole function body.
session.run(
    """
# AArch64: one 32-bit add, then return. The W registers hold the low 32 bits of X0 and X1.
/opt/homebrew/opt/llvm/bin/clang -S -O2 -target arm64-linux-gnu add.c -o add.aarch64.s
sed -n '/^add:/,/.cfi_endproc/p' add.aarch64.s

# x86-64, AT&T order (source first, with % on registers): leal (%rdi,%rsi), %eax does the add.
/opt/homebrew/opt/llvm/bin/clang -S -O2 -target x86_64-linux-gnu add.c -o add.x86_64.s
sed -n '/^add:/,/.cfi_endproc/p' add.x86_64.s

# RISC-V: addw works on the low 32 bits of a0 and a1, so the C int add fits in one instruction.
/opt/homebrew/opt/llvm/bin/clang -S -O2 -target riscv64-linux-gnu add.c -o add.riscv64.s
sed -n '/^add:/,/.cfi_endproc/p' add.riscv64.s
"""
)

# AArch64: one 32-bit add, then return. The W registers hold the low 32 bits of X0 and X1.
$ /opt/homebrew/opt/llvm/bin/clang -S -O2 -target arm64-linux-gnu add.c -o add.aarch64.s
$ sed -n '/^add:/,/.cfi_endproc/p' add.aarch64.s
add:                                    // @add
	.cfi_startproc
// %bb.0:
	add	w0, w1, w0
	ret
.Lfunc_end0:
	.size	add, .Lfunc_end0-add
	.cfi_endproc

# x86-64, AT&T order (source first, with % on registers): leal (%rdi,%rsi), %eax does the add.
$ /opt/homebrew/opt/llvm/bin/clang -S -O2 -target x86_64-linux-gnu add.c -o add.x86_64.s
$ sed -n '/^add:/,/.cfi_endproc/p' add.x86_64.s
add:                                    # @add
	.cfi_startproc
# %bb.0:
                                        # kill: def $esi killed $esi def $rsi
                                        # kill: def $edi killed $edi def $rdi
	leal	(%rdi,%rsi), %eax
	retq
.Lfunc_end0:
	.size	add, .Lfunc_end0-add
	.cfi_endproc

# RISC-V: addw works on the low 32 bits of a0 and a1, so the C int add fits in one instruction.
$ /opt/homebrew/opt/llvm/bin/clang -S -O2 -target riscv64-linux-gnu add.c -o add.riscv64.s
$ sed -n '/^add:/,/.cfi_endproc/p' add.riscv64.s
add:                                    # @add
	.cfi_startproc
# %bb.0:
	addw	a0, a0, a1
	ret
.Lfunc_end0:
	.size	add, .Lfunc_end0-add
	.cfi_endproc

On AArch64 the compiler writes add w0, w1, w0 followed by ret. On x86-64, in AT&T order (source first, with % on register names), it writes leal (%rdi,%rsi), %eax followed by retq — using the lea instruction, meant for address arithmetic, to add two integers in one step. On RISC-V it writes addw a0, a0, a1 followed by ret. Four mnemonics, one addition each, no stack, no spilling. Reading those lines is the shortest way to see whether a change to the C source will cost a branch, a memory access or a cache miss.

Crashes without source. A production segfault, a Windows crash dump or a stripped mobile build gives an engineer an address and a few bytes of context. Everything at that address is assembly; nothing else is available until a symbol server catches up or a core file is downloaded.

Performance work. SIMD, atomic operations, memory barriers, false sharing, dependency chains and branch prediction all sit below the C level. Measurements that disagree with a mental model are usually settled by reading the loop’s assembly.

Security hardening. Stack canaries, control-flow integrity, pointer authentication on AArch64, shadow stacks on x86-64 and RISC-V, and Spectre workarounds all leave visible marks in the compiled binary. Checking that a build really has the hardening its build flags asked for means reading its disassembly.

Operating systems and firmware. A boot sector, a context switch and the first instructions of a kernel have no higher-level language to hide inside. The same is true of inline assembly inside a kernel, a cryptographic library’s constant-time routine or a hot loop in a numerical library.

Generated and third-party code. Protocol buffers, machine-learning kernels, interpreters, just-in-time compilers and bytecode virtual machines often end at an assembly layer. Reading what the build really ships, rather than what the source implies, is the last line of trust.

How every example on this page is proved

Every example on every page of this track is a real file in the lesson’s folder, built and run on a pinned toolchain. The recording of that run — the exact command, the toolchain’s version line, the standard output and standard error merged as a terminal would show them, and the exit status — is saved as JSON beside the file. The lesson’s text reads from the same recording, so a number the prose quotes is a number the run really produced.

For this lesson the host is an Apple M5 Pro laptop on macOS 26.7.1, and the pinned toolchain for the AArch64 code is Apple clang 21.0.0 with the ld-27037.1 linker. The x86-64 and RISC-V object files were produced by Homebrew’s clang 23.1.2 with -target x86_64-linux-gnu and -target riscv64-linux-gnu, without ever running the resulting Linux ELF files: the macOS kernel does not know those system calls, so they run only on Linux, natively or under qemu-user. Reading the bytes with llvm-objdump, by contrast, works here natively; no foreign code is executed to show the three encodings of the exit call.

Three practices make the recording trustworthy. Each example is run twice, and the two runs must print the same thing — a test that depends on random data or on a wall clock fails this step. Addresses that change between runs, such as the base load address otool prints beside each instruction, are written as 0x… by the recording helper, so the record does not look wrong on a re-run. And the pinned clang and linker versions appear in the record itself, so a reader can tell at once whether their own tools match.

Practise

Four questions from the lesson, one at a time, with the idea you know least first. Each answer is explained at once; a miss brings the question back later in the session:

Interview questions

What is the difference between an ISA, assembly language and machine code?

They are three layers of the same idea. An ISA is the contract: the registers a processor exposes, the instructions it accepts, how they are encoded in bytes, and the rules for memory, interrupts and privilege. Machine code is the stream of bytes a processor really reads, written to that contract. Assembly language is a human-readable spelling of those bytes, one line per instruction, with directives, labels and constants that make the file easier to write. An assembler turns the spelling into the bytes, and a disassembler reads the bytes back as the spelling. Each ISA has its own assembly language, because the instructions and registers differ, so a binary built for one does not run on another.

Which three ISAs does this track teach, and where does each one run?

x86-64, AArch64 and RISC-V. x86-64 (Intel 64 and AMD64) runs most PCs and data-centre servers today, developed from the 1970s 8086 line through many extensions. AArch64 is the 64-bit mode of Arm’s A-profile processors, used by every modern smartphone, every tablet and every Apple silicon Mac, with Windows on Arm as a growing desktop case. RISC-V is a newer, open ISA, used in embedded and research work and increasingly in India’s own Shakti and Vega chips as well as Western server and GPU designs. The lesson’s AArch64 example runs natively on Apple silicon; the x86-64 and RISC-V examples need Linux on their own ISA, or qemu-user, to run.

Key takeaways

• Machine code is the stream of bytes a processor reads; assembly language is a human-readable spelling of those bytes, one line per instruction, written to the rules of a particular ISA.
• Three ISAs matter today: x86-64 on PCs and servers, AArch64 on phones and Apple silicon, and RISC-V on open and emerging hardware. The same “return 42” idea becomes different registers and different bytes on each.
• People read assembly to check compiler output, debug crashes without source, work on performance, verify security hardening, write operating systems and firmware, and trust generated or third-party code.
• Every example on this track is a real file built and run on a pinned toolchain; its command, versions, output and exit status are saved as JSON beside the source and shown on the page.
• A disassembler reads the bytes a build wrote and prints the same instructions the assembler produced, so a binary and a listing of its instructions carry the same information in two different forms.