assembly1-1 named x86-64 as the architecture carrying "four decades of backward-compatible accretion," and cpu8bit1-11 closed its own course by naming the Z80's own richness as a preview, at 1976 scale, of exactly this. This chapter is where that promise gets cashed in — the real lineage from a 1978 chip to the architecture running underneath the device this page is being read on, and the single strangest, most concrete fact about it: the CPU never really let go of anything it used to be.

The Lineage — 8086 to x86-64

The whole story starts with the Intel 8086 (1978) — a 16-bit processor, and the direct ancestor of every chip this course covers. It wasn't binary-compatible with the 8080 the way cpu8bit1-5's own Z80 was, but it was deliberately designed so 8080 assembly programs could be mechanically translated into 8086 assembly — the same 8080 lineage cpu8bit1-5 traced through Zilog, now showing up on Intel's own side of the family tree.

• 80286 (1982) — introduced the first, limited version of protected mode, a genuinely new concept this course previews below and covers fully in assembly2-8.
• 80386 (1985) — the big one: a full 32-bit extension (often called IA-32), with complete protected mode and paging. This chip anchored the dominant x86 era for the better part of two decades — "386" became informal shorthand for the entire 32-bit generation.
• Pentium and its successors (1990s–2000s) — continued the 32-bit era while adding the vector-instruction extensions assembly2-9 previews (MMX, and later SSE).
• AMD64 / x86-64 (2003) — the 64-bit extension this entire course is actually about.

Why AMD, Not Intel

Here's the genuinely surprising part: the 64-bit extension to x86 wasn't Intel's idea. Intel's own answer to 64-bit computing was Itanium (IA-64) — a completely new, non-backward-compatible architecture, built from scratch rather than extended from the existing x86 lineage. AMD took the opposite approach: extend the existing, familiar x86 instruction set with 64-bit capability while keeping everything that already worked, working. AMD's approach — AMD64 — won out commercially, and Intel eventually licensed and adopted AMD's own compatible design, selling it under the name Intel 64 (formerly branded EM64T). This is one of the rare, well-documented moments where AMD, not Intel, set the direction the entire industry actually followed.

Real, Protected, and Long Mode — A First Preview

A modern x86-64 CPU doesn't just run in one mode — it can actually behave like several different, much older CPUs, on demand, because the hardware never removed the old behavior when it added new capability:

• Real mode — the original 16-bit, 8086-compatible mode. Every x86-64 PC, including one built this year, literally boots into real mode first, behaving exactly like a 1978 8086, before the operating system switches it into a newer mode.
• Protected mode — the 32-bit mode introduced by the 80286/80386, with real memory protection.
• Long mode — the 64-bit mode this course is actually about, where the registers, addressing, and instructions covered from assembly2-2 onward actually apply.

That boot-time detour through real mode isn't a quirky edge case — it's "four decades of accretion" made completely literal. The chip can still pretend to be its own 1978 ancestor, on command, because nothing from that era was ever actually deleted.

Why This Matters for the Rest of the Course

Every register name, every addressing mode, every instruction covered from here forward exists inside layers of decisions this lineage produced. cpu8bit1-2 and cpu8bit1-5 traced the 6502 and Z80 back to two clean founding constraints, each a single, coherent story. x86-64 doesn't have one story — it has five decades of stories, each one built on top of the last without erasing it. That's the shape this entire course is going to keep tracing, one concrete feature at a time.

Hands-On Exercises

assembly2-1 promised the clearest artifact of x86-64's own history would show up inside a single register's name. Here it is — sixteen general-purpose registers, eight of them carrying four historical layers of naming at once, and eight of them carrying none at all.

The 16 General-Purpose Registers

x86-64 has 16 general-purpose 64-bit registers: RAX, RBX, RCX, RDX, RSI, RDI, RBP, RSP, and R8–R15. That's comparable in scale to cpu8bit1-6's own Z80 total (14, counting the main and shadow sets together) — but with a real difference: all 16 of x86-64's registers are usable simultaneously, with no EXX-style swap ever required to reach half of them.

The first eight trace directly back to the original 8086 (assembly2-1's own starting point), each with a historically-loaded name still partly tied to a specific role: Accumulator, Base, Counter, Data, Source Index, Destination Index, Base Pointer, Stack Pointer. Some of those roles are still real, not just historical trivia — RCX is still the implicit loop counter the LOOP instruction (assembly2-6) automatically decrements, exactly the way its name has promised since 1978.

R8 through R15 are entirely new — added specifically for the 64-bit extension assembly2-1 credited to AMD. They have no inherited name at all, just numbers, because they never needed to carry any legacy forward.

The Sub-Register Maze — RAX/EAX/AX/AH-AL

One physical 64-bit storage location, addressable at four different widths, under four different names:

EAX ("Extended AX") was the whole register back when the 80386 was the newest chip in the lineage. AX was the whole register back in the 8086's own original 16-bit era. AH/AL go back that far too — letting even 1978-era code address just the upper or lower half of a 16-bit value. Nothing here was ever removed; every later chip just added a wider name on top of the one that came before.

The same four-level pattern applies to three more of the original eight: RBX/EBX/BX/BH-BL, RCX/ECX/CX/CH-CL, and RDX/EDX/DX/DH-DL.

Historically, RSI/RDI/RBP/RSP didn't have their own H/L 8-bit forms the way AX/BX/CX/DX did — only their 16-bit SI/DI/BP/SP forms existed classically. x86-64 specifically added new 8-bit low-byte access to these — SIL, DIL, BPL, SPL — using a special encoding prefix. One more concrete instance of assembly2-1's own theme: a genuinely new capability, layered on without ever touching what already existed.

R8–R15's Own Cleaner Pattern

Because R8–R15 never had to inherit an old name, they got a uniform, modern naming scheme from day one: R8 (64-bit), R8D (32-bit, "D" for Double word), R8W (16-bit, "W" for Word), R8B (8-bit, "B" for Byte) — and the exact same pattern for R9 through R15, no exceptions, no historical quirks.

The new registers' naming is strictly more regular than the legacy ones' — a small, direct illustration that code and conventions never carrying old baggage in the first place are simply cleaner than ones that had to accumulate it.

Hands-On Exercises

Before writing real programs, this chapter covers the two things every one of them will lean on: the flags register, and the handful of instructions that set it. It also resolves a real cliffhanger from cpu8bit1-12 — and introduces a genuinely new kind of gotcha neither LC-3 nor the 6502/Z80 ever had: two competing, incompatible-looking ways to write the exact same instruction.

RFLAGS — x86-64's Status Register

cpu8bit1-3's 6502 packed its flags into an 8-bit P register; cpu8bit1-6's Z80 did the same with its 8-bit F register. x86-64's RFLAGS is nominally 64 bits wide — but only a small handful of those bits are actually meaningful flags; the rest are reserved, unused, or hold rarely-touched system-level state. Even the flags register itself carries its own quiet layer of accretion.

The flags this course actually uses:

• CF (Carry Flag) — the same underlying concept cpu8bit1-3 and cpu8bit1-6 both covered.
• ZF (Zero Flag) — set when a result is exactly zero, the same idea as every prior chip's own Z flag.
• SF (Sign Flag) — the same idea as the 6502's N and the Z80's S: set when a result is negative.
• OF (Overflow Flag) — signed overflow, distinct from Carry's unsigned signal, the same distinction cpu8bit1-3 drew for the 6502's own V flag.

Resolving cpu8bit1-12's Cliffhanger

cpu8bit1-12 found that the 6502's CMP and the Z80's CP set Carry in opposite directions for the identical comparison. x86-64 now supplies a third data point — and it sides with the Z80: after a CMP or SUB, CF is set if a borrow was needed (the destination was smaller than the source, unsigned), exactly matching the Z80's own convention, not the 6502's inverted one.

Basic Instructions — MOV, ADD, SUB, CMP

MOV RAX, RBX   ; RAX = RBX (a copy — "MOV" doesn't clear RBX, a slight historical misnomer)
ADD RCX, 5     ; RCX += 5
SUB RDX, RAX   ; RDX -= RAX — sets CF/ZF/SF/OF
CMP RAX, RBX   ; computes RAX - RBX, sets flags, discards the result — like SUB without storing

CMP here is the direct x86-64 counterpart to cpu8bit1-12's own 6502 CMP and Z80 CP — same underlying idea, and, per the resolution above, the same flag convention as the Z80's.

The AT&T vs. Intel Syntax Divide

Here's the genuinely new kind of gotcha: real-world x86-64 code exists in two different syntaxes that look, at a glance, like different instruction sets entirely — even though they describe exactly the same underlying operations.

The same instruction, in both syntaxes:

; Intel syntax (this course)
MOV RAX, RBX
ADD RCX, 5

; AT&T syntax — same two instructions
movq %rbx, %rax
addq $5, %rcx

Hands-On Exercises

Three courses, three addressing stories: LC-3's clean base+offset, the 6502's zero-page workaround, the Z80's displacement-based indexing. x86-64 doesn't pick one — it combines the ideas behind all of them into a single addressing mode genuinely richer than anything either prior course covered, plus one capability neither ever offered at all.

The Addressing Journey So Far

The Full SIB Addressing Mode

x86-64's richest memory operand computes its effective address as:

effective address = Base + (Index × Scale) + Displacement

• Base — any general-purpose register, holding a starting address, playing the same role as the Z80's own HL or the 6502's zero-page pointer.
• Index — any general-purpose register, typically an array index.
• Scale — a multiplier applied to Index, restricted to 1, 2, 4, or 8 — matching byte/word/dword/qword element sizes exactly.
• Displacement — a constant offset, the same role LC-3's PC-relative offset and the Z80's own +d displacement played.

MOV RAX, [RBX + RCX*4 + 8]   ; RBX = array base, RCX = index, *4 for 4-byte elements, +8 skips a header

Why This Matters — No Manual Multiply Required

On the 6502 or Z80, indexing into an array of 4-byte elements would mean multiplying the index by 4 before the address could be computed — typically two shift-left operations, or repeated addition, as a separate step every single time. x86-64's Scale performs that exact multiplication as part of the address computation itself, inside the same instruction that actually accesses memory. This is a genuinely new capability, not just a faster version of something the earlier chips already did.

Not Every Component Is Required

Base, Index, Scale, and Displacement are all optional individually — an instruction only pays for the pieces it actually uses:

MOV RAX, [RBX]              ; base only — like Z80's own (HL)
MOV RAX, [RBX + 8]          ; base + displacement — like Z80's own (IX+d)
MOV RAX, [RBX + RCX]        ; base + index, scale defaults to 1
MOV RAX, [RBX + RCX*4 + 8]  ; all four components together

RIP-Relative Addressing — PC-Relative, Returned

x86-64 also added a genuinely new mode: [RIP + offset], computing an address relative to the current instruction pointer. This is conceptually the exact same idea as assembly1-3's own LC-3 PC-relative LD — but for a completely different, distinctly modern reason. LC-3 needed PC-relative addressing because a 16-bit instruction had no room for a full address at all. x86-64 doesn't have that bit-budget problem (assembly2-1's own variable-length instructions solve it) — RIP-relative addressing exists instead to support position-independent code: a program whose data references stay correct no matter where in memory the operating system actually loads it, a real security and shared-library requirement neither LC-3 nor the 6502/Z80 ever had to think about. The same underlying technique, reinvented decades later to solve an unrelated problem.

Hands-On Exercises

assembly1-7 built one simple, self-invented LC-3 calling convention. cpu8bit1-12 used one straightforward subroutine convention per chip. This chapter is where that simplicity ends: x86-64 doesn't have a calling convention — it has (at least) two real, competing, mutually incompatible standards, and getting the wrong one is a genuine way to crash a real program.

The Stack — RSP and RBP

RSP is a full 64-bit stack pointer, free to point anywhere — as fully general as the Z80's own SP from cpu8bit1-7, with no 6502-style page lock. PUSH/POP are native instructions, operating on 64-bit values by default in long mode.

RBP plays a role neither LC-3 nor the 6502/Z80 ever formally needed: a stable frame pointer. As a function runs, RSP itself keeps moving — every push and pop shifts it. RBP is set once, at the start of a function, and held fixed for its entire duration, giving a stable reference point for that function's own parameters and local variables regardless of how RSP moves around them. It's conceptually the same idea as the 6502/Z80's own convention of dedicating a register to a specific job (cpu8bit1-3's own R6-as-stack-pointer precedent from assembly1-7) — just applied to a genuinely new problem, deep local-variable frames, that this arc's simpler subroutines never had.

Worth an honest, brief note: modern compiled code often skips the frame pointer entirely ("frame pointer omission"), computing local-variable offsets directly from RSP instead, as a performance optimization. RBP is a real, common convention, not a hardware requirement.

Register-Based Argument Passing — A Genuine Departure

Neither assembly1-7's LC-3 subroutines nor cpu8bit1-12's own capstone formally passed "arguments" at all — a value was just already sitting in whatever register the subroutine happened to expect, by ad-hoc agreement between caller and callee. Real x86-64 calling conventions formalize this completely: the first several arguments to a function are passed directly in specific, standardized registers, not via the stack — the stack is reserved for overflow arguments beyond that fixed count, and for local storage.

Two Competing Standards

This is the real complexity: which registers hold which arguments depends entirely on which operating system the code targets.

A concrete example — calling a hypothetical function with three integer arguments:

; System V AMD64 ABI (Linux/macOS)
MOV RDI, 10   ; 1st argument
MOV RSI, 20   ; 2nd argument
MOV RDX, 30   ; 3rd argument
CALL some_function

; Microsoft x64 (Windows) — same call, different registers
MOV RCX, 10   ; 1st argument
MOV RDX, 20   ; 2nd argument
MOV R8, 30    ; 3rd argument
SUB RSP, 32   ; reserve the required 32-byte shadow space first
CALL some_function

One more real, shared rule worth naming: in both conventions, RBX, RBP, and R12–R15 are callee-saved — a called function must preserve their values before returning, exactly the register-preservation discipline assembly1-7 first established for R7 and cpu8bit1-12's own capstone reinforced by deliberately choosing C over B.

Why Real Programs Must Actually Care

In every prior course, "the calling convention" was something the programmer invented for their own self-contained program — nothing outside that program ever needed to agree with it. x86-64 calling conventions are a real contract: honoring them correctly is what lets hand-written assembly interoperate with the operating system, system libraries, and code compiled by an entirely different compiler. Get it wrong, and the failure isn't a logic bug in your own code — it's a silent violation of an agreement code outside your control was relying on, often surfacing as a crash or corrupted data far from the actual mistake.

Hands-On Exercises

Jumps and loops will feel familiar after two full prior courses of them. This chapter covers that familiar ground quickly, then introduces something genuinely new: a way to make a decision without ever branching the instruction pointer at all.

Unconditional and Conditional Jumps

JMP is unconditional, the same idea as the 6502's own JMP or LC-3's BRnzp. The conditional Jcc family reads RFLAGS the same way assembly2-3 already covered — including JC/JNC, a direct parallel to cpu8bit1-8's own 6502 BCC and cpu8bit1-12's own Z80 JR NC, now with the flag convention already settled in assembly2-3.

LOOP — A DJNZ-Style Instruction

x86-64 has a native LOOP instruction: decrement RCX, and jump if RCX isn't zero — one instruction, doing exactly what cpu8bit1-8's own Z80 DJNZ does.

MOV RCX, 5
LOOP_START
        ...                ; loop body
        LOOP LOOP_START  ; RCX-- ; jump to LOOP_START if RCX != 0

CMOV — A Genuinely New Idea: Branchless Code

Nothing in assembly1 or cpu8bit1 offered this: CMOVcc conditionally moves a value based on the current flags — but the instruction itself always executes, with no branch taken either way. A decision, without ever redirecting the instruction pointer.

CMP  RAX, RBX
CMOVL RAX, RBX   ; if RAX < RBX (signed), RAX becomes RBX — branchless max

Compare this directly against cpu8bit1-12's own capstone, which found a maximum using an explicit CMP/branch/STA sequence on both the 6502 and Z80 — real branches, genuinely taken or not taken. CMOVL computes the identical logical result without a single conditional jump anywhere in the sequence.

Why this matters: modern CPUs rely heavily on branch prediction and deep instruction pipelining (concepts this course hasn't needed until now) to run fast. A mispredicted branch forces the CPU to discard speculative work and refill its pipeline — a real, measurable cost. For simple "if condition, then set this value" patterns, CMOV sidesteps misprediction risk entirely, since there's no branch to mispredict in the first place.

Hands-On Exercises

Step back from individual instructions for a moment. cpu8bit1-11 formalized RISC vs. CISC using a 56-instruction chip and a ~158-instruction chip as its two data points. This chapter adds the third, modern one — and finds the clean binary that comparison suggested is, at this scale, more complicated than it first looked.

Counting the Instructions — A Genuinely Hard Question

assembly1-5's LC-3 had a small, exact, countable opcode set. cpu8bit1-2 counted 56 6502 mnemonics; cpu8bit1-5 counted roughly 158 for the Z80. x86-64 doesn't have an equally clean number to cite. Base integer instructions alone already number in the hundreds; once every SIMD/vector extension family (assembly2-9's own preview) is counted as its own set of distinct mnemonic-and-operand-form combinations, the real total runs into the thousands. This chapter deliberately doesn't cite one precise figure — pinning down an exact count depends entirely on what's being counted, and a false-precision number would be less honest than admitting the real answer is "a lot, by any reasonable measure, and the exact figure depends on your counting method."

Why So Many — Extending cpu8bit1-5's Own Trick

cpu8bit1-5 explained the Z80's CB/DD/ED/FD prefix bytes as a way to unlock additional opcode spaces beyond a single byte's own 256-value ceiling. x86-64 uses exactly the same underlying idea, stacked several layers deeper: a 0x0F escape byte (in use since the 80386 era) unlocks an entire second opcode table; the REX prefix (already named in assembly2-2 as the mechanism behind SIL/DIL/BPL/SPL and R8–R15 access) unlocks 64-bit operand sizes and the extended register set; and further escape sequences layer entire SIMD instruction families (assembly2-9) on top of all of that. It's the identical mechanism the Z80 pioneered at a small, four-prefix scale — just applied many more times over.

A Brief, Honest Tour of Instruction Categories

Cataloging the full instruction set is explicitly out of scope for this course — instead, a categorized overview:

• Data movement — MOV and its relatives, including MOVZX/MOVSX (zero-extend / sign-extend a smaller value into a larger register), directly relevant to assembly2-2's own sub-register material.
• Arithmetic and logic — ADD/SUB/MUL/DIV/AND/OR/XOR/NOT/NEG, plus specialized variants.
• Control flow — covered in full in assembly2-6.
• String/memory-block instructions — MOVS/CMPS/SCAS/STOS, combined with a REP prefix to repeat an operation across an entire block of memory as one conceptual instruction. A genuinely distinctive x86 family with no real equivalent in LC-3 or the 8-bit chips this arc covered.
• Bit manipulation — instructions like BT/BTS/BTR and POPCNT for testing, setting, and counting individual bits directly.
• System/privileged instructions — previewed fully in assembly2-8.
• SIMD/vector instructions — previewed fully in assembly2-9.

RISC vs. CISC, Confirmed — and Complicated — at Modern Scale

By raw instruction count, x86-64 is exactly what cpu8bit1-11 predicted the Z80 previewed: the CISC trajectory, taken to modern scale.

But the real, honest ending to this comparison is more nuanced than "x86-64 proves CISC won." Modern x86-64 CPUs internally translate their own complex, CISC-style instructions into simpler internal micro-ops, executed on hardware that itself behaves in a genuinely RISC-like way — uniform, pipeline-friendly operations under the hood. The instruction set a programmer writes is CISC; the microarchitecture actually running it, underneath, borrows heavily from RISC's own design lessons. cpu8bit1-11's own clean binary — a chip is either RISC or CISC — was accurate for two 1970s designs studied at the instruction-set level. At this modern scale, the two philosophies don't compete anymore; they coexist inside the same chip, at different layers.

Hands-On Exercises

Every chapter so far has extended something the prior arc already covered — richer registers, richer addressing, richer instructions. This chapter is different: it's genuinely new ground. Nothing in assembly1 or cpu8bit1 has an equivalent for what's about to be covered, because neither LC-3 nor the 6502/Z80 enforce any concept of trust at all.

A Genuinely New Kind of Chapter

Every instruction covered across both prior courses could be executed by literally any code running on those chips. LC-3 has no privileged instructions; the 6502 and Z80 have none either — no rings, no memory protection, no hardware-enforced OS/user distinction anywhere in either design. x86-64 is fundamentally different: the CPU itself enforces a hierarchy of trust, and certain things simply cannot be done from the wrong level, no matter what the program tries.

Protection Rings — 0 Through 3

• Ring 0 — kernel/OS mode. Full access to every instruction, every memory location, every piece of hardware. This is where the operating system kernel itself runs.
• Ring 3 — user mode. Restricted. Ordinary application programs run here, and a specific category of instructions — ones that reconfigure paging, change privilege level, or touch hardware directly — are simply forbidden. Attempting one doesn't fail silently; it triggers a CPU exception.

This is the real hardware mechanism behind assembly1-8's own OS/hardware boundary concept — LC-3's TRAP was a clean, simplified stand-in for exactly this idea: user code cannot directly do privileged things, and has to go through a controlled channel instead. assembly2-10 covers that channel's real, modern form.

Virtual Memory via Paging

Every running process sees its own private, seemingly complete address space — even though many processes actually share the same physical RAM underneath. Paging is the mechanism: memory is divided into fixed-size chunks (pages, typically 4KB), and the CPU's own hardware, guided by OS-managed page tables, translates every virtual address a program's instructions reference into a real physical address, on every single memory access.

If a virtual address has no valid mapping in a process's own page table, any attempt to touch it raises a page fault — a real, controlled CPU exception.

Closing assembly2-1's Own Loop

Recall assembly2-1's own three modes: real, protected, and long. Now their real difference can be stated precisely:

• Real mode has no paging and no protection at all — a program running in real mode has exactly the same total, unguarded access to memory that every LC-3, 6502, and Z80 program in this entire arc has always had. Booting into real mode isn't just "acting like an old chip" in spirit — it's a genuine, temporary return to zero memory protection.
• Protected mode (introduced by the 80386, assembly2-1's own lineage) is where paging and rings first appear.
• Long mode — this course's real subject — uses an extended, deeper paging structure to address vastly more memory than 32-bit protected mode ever could.

An instruction attempted from the wrong ring doesn't just quietly fail — it raises a specific, named, well-documented exception: the General Protection Fault (#GP), a real CPU-level event any programmer doing low-level debugging eventually meets in person.

Hands-On Exercises

Every instruction covered since assembly1-1 — across all three courses — has operated on one piece of data at a time. This chapter previews something genuinely different: instructions that operate on several pieces of data at once. Deliberately light-touch, on purpose — this is honestly a topic large enough to be its own course.

Why Vector Instructions Exist — SIMD in One Idea

SIMD — Single Instruction, Multiple Data. Every ordinary instruction this entire arc has covered works on one value: one register, one memory operand. Adding two 4-element arrays together the ordinary way takes four separate ADD instructions, one pair at a time. A SIMD instruction packs several values into one wide register and performs the same operation on all of them simultaneously, inside a single instruction's own execution — not four instructions doing one thing each, but one instruction doing four things at once.

The Real Lineage — MMX → SSE → AVX

MMX's own register-sharing compromise meant a program couldn't freely mix MMX instructions with ordinary floating-point math without real overhead switching between the two uses of the same physical registers. SSE fixed this by giving vector instructions their own dedicated register file entirely. This whole lineage is one more concrete instance of assembly2-1's own "four decades of accretion" theme — SIMD has its own internal history of layered extensions, each one adding capability on top of the last, mirroring assembly2-2's own RAX/EAX/AX nesting, just for an entirely different feature.

One Worked Example

Adding two 4-element arrays of single-precision floats, the SIMD way:

MOVUPS XMM0, [array1]   ; load 4 floats from array1 into XMM0
MOVUPS XMM1, [array2]   ; load 4 floats from array2 into XMM1
ADDPS  XMM0, XMM1       ; add all 4 pairs simultaneously — ONE instruction
MOVUPS [result], XMM0   ; store all 4 results back at once

ADDPS — ADD Packed Single-precision — the mnemonic itself describes exactly what it does. The equivalent ordinary, scalar version of this same task would need four separate ADD-family instructions, one value pair at a time; ADDPS does all four in one.

Honestly Scoping This Topic

This is genuinely as far as this course goes. A real, complete treatment of SIMD would need to cover the many packed integer/float data-type variants, each instruction set's own feature-detection requirements, real memory-alignment rules (some SIMD instructions fault on unaligned memory operands), and AVX-512's own further masking and broadcasting capabilities. All of that is large enough to be a genuinely separate course on its own — this chapter deliberately stops here rather than pretending a shallow tour is complete coverage.

Hands-On Exercises

assembly2-8 established that ring-3 code can't do privileged things directly — it has to ask. This chapter covers how it actually asks, and the answer genuinely splits in two depending on which operating system is listening.

Recap — assembly1-8's Clean Abstraction

LC-3's TRAP was one unified mechanism: a single instruction, one vector table, a small fixed set of OS services (GETC/OUT/PUTS/HALT) defined by the LC-3 specification itself, identical on every LC-3 system that ever exists. Real x86-64 has no equivalent single mechanism — what "asking the OS" even looks like depends entirely on which operating system the code is running under.

Linux — The SYSCALL Instruction

x86-64 Linux provides a dedicated SYSCALL instruction — a fast, purpose-built replacement for the older, slower software-interrupt-based mechanism (INT 0x80) that 32-bit x86 Linux used. The convention: the syscall number goes in RAX, and arguments go in RDI, RSI, RDX, R10, R8, R9.

MOV RAX, 1     ; syscall number for write()
MOV RDI, 1     ; file descriptor 1 = stdout
MOV RSI, msg   ; pointer to the string
MOV RDX, 5     ; length
SYSCALL          ; make the call — return value comes back in RAX

The return value comes back in RAX — the one point of real consistency with assembly2-5's own ordinary function-call convention.

Windows — No Direct Syscalls for Applications

Windows takes a genuinely different approach. It does not expose a stable, documented, directly-invokable syscall interface to ordinary application code the way Linux does — Windows's own internal syscall numbers are considered private implementation detail, and can (and do) change between versions and even updates. Instead, applications call into the Windows API (Win32 API): a large collection of ordinary functions, living in system DLLs like kernel32.dll, which themselves make the real, internal, unstable syscalls on the application's behalf.

The practical consequence: an x86-64 Windows assembly program calling something like WriteFile or ExitProcess does so with an ordinary CALL instruction, using assembly2-5's own Microsoft x64 calling convention, to a function imported from a DLL — not via any direct syscall-style instruction the programmer writes.

A Genuine, Important Divergence

This is the real point: LC-3 had one portable OS abstraction, identical everywhere. x86-64 genuinely has two different models depending on target OS — code written to make Linux syscalls directly has no Windows equivalent to fall back on, and vice versa, even though the underlying CPU instructions covered in every prior chapter of this course work identically on both.

Hands-On Exercises

assembly1-9 taught the two-pass assembler algorithm, symbol tables, object files, and linking using LC-3 as the example. This chapter is the confirmation that none of that was simplified for teaching purposes — real, modern tools do exactly the same thing, just at real-world scale.

NASM and GAS — Two Real Assemblers

NASM (Netwide Assembler) uses Intel syntax — matching this course's own committed choice from assembly2-3 — and is widely used for standalone, hand-written assembly projects with a simple, self-contained command-line workflow. GAS (GNU Assembler, part of binutils) uses AT&T syntax by default and is the assembler GCC itself uses internally to emit its own generated assembly — it's what shows up when reading compiler output or inline assembly inside C code, deeply embedded in the Linux/GNU toolchain.

For hand-writing assembly directly — what every example in this course has been doing — NASM's Intel syntax and simpler standalone workflow are typically the more approachable starting point; GAS becomes unavoidable the moment the goal shifts to reading or embedding assembly inside compiler-generated code.

assembly1-9's Own Two-Pass Assembler, For Real

Real assemblers use the exact same two-pass approach assembly1-9 taught, for the exact same reason: Pass 1 builds a symbol table by scanning the whole file first; Pass 2 generates real machine code, resolving forward references against that already-complete table. This isn't a simplified teaching model real tools have since moved past — it's genuinely how NASM and GAS work today.

The directives differ in spelling but not in job — assembly1-9's own "instructions to the assembler, not the CPU" idea still applies exactly:

Object Files and Real Linking

Real x86-64 toolchains produce real object files (.o on Linux, .obj on Windows), and a real linker — ld on Linux, link.exe on Windows — does exactly the job assembly1-9 described: resolving cross-file references, combining multiple object files, and (for real programs) linking against system libraries, into one final executable.

What's genuinely new here: a real executable isn't just raw bits sitting at a fixed address the way LC-3's own simple model was. It's a structured, documented file format.

ELF vs. PE — Real Executable Formats

Linux (and most Unix-like systems) use ELF (Executable and Linkable Format); Windows uses PE (Portable Executable). Both exist to carry information a flat block of bits never could: where the program's entry point is, which external libraries need to be dynamically linked in — and, directly connecting back to assembly2-8's own paging material, which memory permissions each section of the program needs. A file format explicitly marks which parts are code (executable), which are data (writable), and which are read-only constants — and it's precisely this information the OS loader uses to set up the actual per-page protections assembly2-8 covered. The file format isn't just packaging; it's the literal source of the information ring-3 memory protection is built from.

A Minimal Real Build Pipeline

Conceptually — this chapter illustrates the shape of the real pipeline rather than serving as a full setup tutorial:

# Linux, via NASM + ld
nasm -f elf64 program.asm -o program.o
ld program.o -o program

# Windows, via NASM + a Windows linker
nasm -f win64 program.asm -o program.obj
; (linked with link.exe or an equivalent)

Hands-On Exercises

One real, working NASM program, closing not just this course but the entire three-course Assembly/Machine Language arc: a function call using a genuine calling convention, an array walked with full SIB addressing, and output produced through a real Linux syscall.

The Program

Sums a small array of five integers using a real function (not inlined code), then prints the single-digit result.

section .data
    array    dq 1, 2, 1, 3, 1      ; 5 qwords — kept small so the sum stays a single digit
    outbuf   db 0, 10              ; byte 0: the digit (filled in below); byte 1: newline

section .text
global _start

; --- Function: sum_array ---
; Input:  RDI = array pointer, RSI = element count (System V AMD64 ABI, assembly2-5)
; Output: RAX = sum
sum_array:
        PUSH RBP
        MOV  RBP, RSP        ; a real stable frame pointer (assembly2-5)
        XOR  RAX, RAX        ; RAX = running sum = 0
        XOR  RCX, RCX        ; RCX = index = 0 (caller-saved — safe to clobber freely)
.loop:
        CMP  RCX, RSI
        JE   .done
        ADD  RAX, [RDI + RCX*8]   ; full SIB addressing (assembly2-4): Base + Index*Scale
        INC  RCX
        JMP  .loop
.done:
        POP  RBP
        RET

_start:
        LEA  RDI, [rel array]    ; 1st argument — RIP-relative addressing (assembly2-4)
        MOV  RSI, 5            ; 2nd argument — element count
        CALL sum_array         ; a real function call, System V convention (assembly2-5)

        ADD  AL, '0'          ; digit -> ASCII, assembly1-10's own single-digit trick, echoed here
        MOV  [rel outbuf], AL

        MOV  RAX, 1            ; syscall number for write() (assembly2-10)
        MOV  RDI, 1             ; fd = stdout
        LEA  RSI, [rel outbuf]
        MOV  RDX, 2             ; length — digit + newline
        SYSCALL

        MOV  RAX, 60            ; syscall number for exit()
        XOR  RDI, RDI          ; exit code 0
        SYSCALL

Assembled and linked exactly the way assembly2-11 described: nasm -f elf64 program.asm -o program.o, then ld program.o -o program. Running it prints 8 followed by a newline.

Chapter Attribution — All Three Courses

Closing the Full Arc

Three courses, one throughline, stated first in assembly1-1: strip away real-hardware history and teach the universal concepts cleanly (LC-3), then meet two real, historically important 1970s chips shaped by genuinely opposite founding constraints (the 6502 and Z80), then meet the real, modern architecture carrying every one of those forces forward, compounded, for four more decades (x86-64). Registers grew from LC-3's uniform eight, to the 6502's cost-starved three and the Z80's shadow-doubled fourteen, to x86-64's sixteen — each carrying its own real history in its own names. Addressing grew from a single PC-relative formula, to zero page and (IX+d), to a single instruction computing Base+Index×Scale+Displacement. Stacks grew from entirely hand-built, to real-but-page-locked, to real-and-fully-flexible, to a modern frame pointer inside a real function. And the RISC-vs-CISC question cpu8bit1-1 only previewed got a full, honest answer: confirmed at modern scale, and then honestly complicated by the discovery that a CISC instruction set can run on a genuinely RISC-like microarchitecture underneath. This capstone is the last, concrete proof that every one of those threads was real — not just described, but written, and run.

Hands-On Exercises