Assembly Programming: Anti-Patterns, Contested Questions, Currency, and Canon¶
Part 4 of 4 of the Assembly Programming reference (plugin
assembly-programming), covering §15–§20. Sibling skills:assembly-fundamentals-and-isas(§0–§5),assembly-toolchain-performance-and-simd(§6–§10),assembly-systems-crypto-and-inline(§11–§14). Section numbers are shared across the set; a reference written as §N →skillpoints into that sibling skill.Currency: Verified August 2026. See §17 below for the currency snapshot and what goes stale first.
How to read this. Reference, not tutorial. Sections are independent. Three markers: - [DURABLE] — machine organization, algorithms, or a lesson that has held since the 1970s. Does not expire. - [ISA] — specific to x86-64, AArch64, RISC-V, or a particular microarchitecture. Verify against the vendor's current manual. - [CONTESTED] — practitioners genuinely disagree, usually about how much hand-written assembly is justified.
⚠️ GOTCHA boxes mark the mistakes that produce silent corruption, ABI violations, or code that is slower than the C you replaced.
The three framings that organize everything below: 1. The instruction set is an interface, not the machine. The CPU you're actually programming is out-of-order, superscalar, speculative, and cached. Your instructions are decoded into µops, reordered, and executed in parallel. Reasoning about assembly as "the CPU does this, then this" is wrong in ways that make your optimizations wrong. 2. Reading assembly is a hundred times more common than writing it, and more valuable. Most of the return here comes from understanding compiler output, debugging an optimized crash, or reverse-engineering a binary. 3. When you write assembly, you are taking on the compiler's job permanently. No retargeting, no auto-vectorization, no new-CPU tuning, and no help from the next twenty years of compiler improvements. That's the real cost, and it's paid in maintenance rather than in the initial write.
§15. Anti-Patterns¶
| Anti-pattern | Why | Instead |
|---|---|---|
| Writing assembly before profiling | You'll optimize code that doesn't matter | Profile; then §0.1 → assembly-fundamentals-and-isas's ladder |
| Hand-written asm where intrinsics would do | You give up register allocation, scheduling, inlining | Intrinsics (§13.1 → assembly-systems-crypto-and-inline) |
| Optimizing instruction count | Cache misses and mispredicts dominate by 100× | Optimize the dependency chain and memory (§9.1 → assembly-toolchain-performance-and-simd) |
| Clobbering a callee-saved register | Corruption surfaces in the caller, arbitrarily later | Know the ABI (§6 → assembly-toolchain-performance-and-simd); test with poison values (§14 → assembly-systems-crypto-and-inline) |
| Misaligning the stack | Faults inside unrelated library code | 16-byte alignment at every call |
| Assuming System V on Windows | Different arg registers, shadow space, xmm6–15 saved | Per-platform code paths |
| Assuming AArch64 saves all of v8–v15 | Only the low 64 bits are callee-saved | Save the full registers yourself |
| Using the red zone in kernel/interrupt code | It doesn't exist there | -mno-red-zone, explicit stack |
| Omitting CFI directives | No backtraces, broken unwinding, misattributed profiles | .cfi_* on every function (§7.2 → assembly-toolchain-performance-and-simd) |
Writing to ax/al instead of eax |
Partial-register merge stall | 32-bit ops zero-extend for free (§2.1 → assembly-fundamentals-and-isas) |
loop, or branch-hint prefixes on x86 |
Slower / ignored for two decades | dec/jnz; nothing |
| Reusing one accumulator in a reduction | Serializes on latency | Multiple accumulators (§9.2 → assembly-toolchain-performance-and-simd) |
Forgetting vzeroupper |
AVX↔SSE transition penalties | Emit it before returning |
| Assuming AVX-512 / SVE2 / SME are present | Wildly uneven deployment | Runtime dispatch via CPUID/HWCAP |
| Porting concurrent code from x86 without adding barriers | TSO hid the missing barrier; ARM/RISC-V won't | Understand the memory model (§1.4 → assembly-fundamentals-and-isas) |
| JIT: writing bytes without I-cache invalidation | Works on x86 (coherent I-cache), breaks on ARM/RISC-V | dc cvau/ic ivau/isb, or fence.i (§11 → assembly-systems-crypto-and-inline) |
Inline asm without "memory"/"cc"/&/volatile |
Works at -O0, fails at -O2 |
Get the clobbers right (§13.2 → assembly-systems-crypto-and-inline) |
| Branching or table-indexing on secret data | Timing side channel | Constant-time discipline (§12 → assembly-systems-crypto-and-inline) |
| Assuming constant-time arithmetic by default on modern Intel | Not guaranteed by default on Ice Lake / Gracemont and later | Understand DOIT/DIT/Zkt (§12.2 → assembly-systems-crypto-and-inline) |
| Optimizing from a 20-year-old guide | Half of it was Pentium 4 lore | Agner Fog / uops.info, and measure |
| No differential test against a C reference | Assembly bugs are subtle and data-dependent | Random differential testing (§14 → assembly-systems-crypto-and-inline) |
| Hand-writing crypto assembly with no verification story | The stakes are maximal and the failure is silent | Jasmin / HACL* / fiat-crypto (§12.3 → assembly-systems-crypto-and-inline) |
§16. Contested Questions¶
16.1 Does hand-written assembly still beat compilers? For: in narrow kernels — crypto, codecs, string/parsing primitives — with a knowledgeable author on a known microarchitecture, yes, and measurably. Against: the gap closed enormously, compilers retarget for free, and most claimed wins evaporate under proper benchmarking or on the next CPU generation. The synthesis practitioners actually apply: intrinsics for almost everything, assembly for the last few percent on the few kernels that justify permanent maintenance.
16.2 CISC vs. RISC. Largely a resolved non-question — both decode to internal µops and the ISA-level distinction matters far less than it did. What survives is real: decode complexity and code density (x86 pays for the first, gains on the second), and the argument that a clean ISA is cheaper to implement and verify.
16.3 Fixed-width SIMD vs. scalable vectors. For scalable: one binary across vector widths, no epilogue, future-proof. Against: harder to reason about, harder to hand-schedule, less mature tooling, and you can't see the register width you're working with. The industry is split — x86 doubled down on fixed-width with AVX10, while ARM and RISC-V both chose scalable.
16.4 AVX-512's ISA design. For: mask registers and 32 registers are genuinely excellent, and it's the most capable SIMD ISA. Against: Linus Torvalds' well-known criticism — fragmentation, downclocking, and die area spent on benchmarks rather than real code. AVX10 is Intel conceding the fragmentation half of that argument.
16.5 Should you learn assembly at all? For: it's the only way to understand what your machine and your compiler actually do, and it's indispensable for debugging optimized code, security work, and systems programming. Against: as a writing skill it's applicable to a shrinking share of work. The consensus is to learn to read fluently and write rarely.
16.6 Which ISA to learn first. RISC-V is the best-designed teaching target and the easiest to hold in your head. AArch64 is the best balance of clean design and real-world ubiquity. x86-64 is the ugliest and the one whose disassembly you're most likely to have to read. Learning any one makes the next much easier.
§17. Currency Snapshot — verified August 2026¶
| Thing | Status as of Aug 2026 | Decay risk |
|---|---|---|
| Intel APX | Doubles GPRs to 32, adds a unique destination register for integer instructions (i.e. non-destructive three-operand x86), and extends predication. Intel reports ~10% fewer loads and ~20% fewer stores in compiled code. Described as the most significant x86 ISA update since the move to 64 bits | Medium |
| AVX10 | The convergence effort to clean up AVX-512: one ISA across P-cores and E-cores, with mask registers and 256-bit as the common denominator. From AVX10.2 spec rev 4.0, Intel declared AVX10/512 will be used across all product lines, supporting 128/256/512 in all lines — dropping the earlier AVX10/256-only plan (LLVM/Clang 22 correspondingly dropped the 256-bit-only options) | Medium |
| Nova Lake | ⚠️ Intel's Instruction Set Extensions and Future Features manual rev 060 (November 2025) confirms Nova Lake supports AVX10.1, AVX10.2, APX, plus SM4 (EVEX), MOVRS and PREFETCHRST2 — ending months of rumours it would ship without them. Launching as Core Ultra 400, second half of 2026 | High |
| RISC-V RVA23 | Ratified 21 October 2024. ⚠️ The V (vector) extension is now MANDATORY (optional in RVA22). Also newly mandatory: Zvfhmin, Zvbb, Zvkt, Zihintntl, Zicond, Zimop, Zcmop, Zcb, Zfa, Supm. Baseline for the Android RISC-V ABI. Scalar crypto Zkn/Zks removed as options — the goal is to move the ecosystem to vector crypto. Ratified specs are frozen and never revised | Low |
| RVV | v1.0 ratified 2021. VLA model; 32 vector registers; shipping VLEN from 128 to 16384 bits; SEW and LMUL set dynamically by vsetvli |
Low |
| Arm SVE2 / SME | SVE2 mandatory in Armv9-A. SME was added to the Arm ARM for A-profile on 20 March 2024. ⚠️ Apple M4 was the first consumer-grade silicon supporting both SVE2 and SME (Apple's LLVM contribution specifies Armv9.2-A for M4 and confirms SME and SME2). Arm's Lumex cores bring SME2 to Android; some custom cores shipped SME1+SVE2 first. Deployment remains uneven — runtime-detect | High |
| Intel DOIT | Constant-time guarantees held by default only before Ice Lake (Core) and Gracemont (Atom). On those and later they must be explicitly enabled via IA32_UARCH_MISC_CTL bit 0. Intel does not recommend enabling globally. Kernel-only (MSR). Explicitly covers data-dependent prefetchers |
Medium |
| Arm DIT | PSTATE.DIT, Armv8.4+. Unprivileged and cheap to set from user space. Linux enabled it for arm64 in v6.2 — kernel only; user space must opt in. ⚠️ Guarantee is scoped to the registers an instruction explicitly uses, and makes no statement about DMPs |
Medium |
| RISC-V constant-time | Zkt (scalar) and Zvkt (vector) attest data-independent execution latency for their instruction subsets. Zvkt is mandatory in RVA23 — arguably the cleanest of the three vendors' approaches | Low |
| LLVM constant-time intrinsics | In development as of late 2025; lowers to CSEL on AArch64, masked arithmetic elsewhere. Rust Crypto, BearSSL, and PuTTY maintainers interested in replacing inline-assembly workarounds |
High |
Goes stale fastest: Nova Lake / APX / AVX10 shipping status; SME deployment across
vendors; LLVM constant-time intrinsics. Essentially never stale: §1 → assembly-fundamentals-and-isas (machine model),
§6 → assembly-toolchain-performance-and-simd (ABIs), §8 → assembly-toolchain-performance-and-simd (reading disassembly), §9 → assembly-toolchain-performance-and-simd (performance fundamentals), §12.1 → assembly-systems-crypto-and-inline (the three
constant-time rules), §15 (anti-patterns).
§18. The Canon¶
18.1 The vendor manuals — and here they genuinely are the field¶
- Intel® 64 and IA-32 Architectures Software Developer's Manuals — Volume 2 is the instruction reference; Volume 3 is systems programming. Also the Optimization Reference Manual and the Instruction Set Extensions and Future Features manual (where APX and AVX10 live).
- AMD64 Architecture Programmer's Manual + the Software Optimization Guide per family. Read both vendors' manuals — they differ on details that matter.
- Arm Architecture Reference Manual (Arm ARM) for A-profile, and the Software Optimization Guides per core (Neoverse, Cortex-X/A). Arm's Developer site and the Learn the Architecture series are unusually good.
- RISC-V ISA specifications (unprivileged and privileged) and the Ratified
Specifications Library at
docs.riscv.org, plus riscv/riscv-profiles on GitHub for RVA23. - System V ABI: AMD64 Architecture Processor Supplement, AAPCS64, and the
RISC-V psABI — the calling-convention documents in §6 →
assembly-toolchain-performance-and-simd.
18.2 The performance references¶
- Agner Fog's manuals (
agner.org/optimize) — five volumes, free, and the instruction tables are the canonical latency/throughput/port reference for every x86 microarchitecture. If you optimize x86, this is not optional. - uops.info — automated, exhaustive, machine-measured instruction data.
- Intel intrinsics guide (
intel.com/content/www/us/en/docs/intrinsics-guide) and Arm's Neon/SVE intrinsics references. - Brendan Gregg, Systems Performance — for the layer above.
- Ulrich Drepper, "What Every Programmer Should Know About Memory" — dated in specifics,
still the best explanation of why §9.3 →
assembly-toolchain-performance-and-simdis the section that matters.
18.3 Books¶
| Author | Work | Why |
|---|---|---|
| Bryant & O'Hallaron | Computer Systems: A Programmer's Perspective (CS:APP) | The best book for learning assembly in context. Teaches x86-64 as part of understanding the whole machine |
| Patterson & Hennessy | Computer Organization and Design (RISC-V edition) | The undergraduate standard, now RISC-V-based |
| Hennessy & Patterson | Computer Architecture: A Quantitative Approach | The graduate one — why microarchitecture is what it is |
| Randall Hyde | The Art of Assembly Language | Comprehensive, opinionated, good on fundamentals |
| Daniel Kusswurm | Modern X86 Assembly Language Programming; Modern Arm Assembly | The most current practical SIMD-focused books |
| Ray Seyfarth | Introduction to 64 Bit Assembly Programming | Clean, modern, Linux-focused |
| Pyeatt & Ughetta | ARM 64-Bit Assembly Language | Solid AArch64 treatment |
| Waterman & Asanović | The RISC-V Reader | Short, excellent, by the architects |
| Eldad Eilam | Reversing: Secrets of Reverse Engineering | The reading-assembly discipline |
| Dennis Andriesse | Practical Binary Analysis | Modern, tool-focused |
| Chris Kaspersky | Code Optimization: Effective Memory Usage | Dated but instructive |
| Warren | Hacker's Delight | Bit-twiddling algorithms — the raw material of good assembly |
| Abrash | Graphics Programming Black Book | Historically important, and the best writing about the craft of optimization ever published. Read it for the method, not the numbers |
18.4 Online and people¶
Compiler Explorer (godbolt.org — Matt Godbolt) is the single best tool; his talks on
"what has my compiler done for me lately" are the best introduction to reading assembly.
Agner Fog, Daniel Lemire (SIMD parsing, simdjson), Wojciech Muła
(0x80.pl — SIMD algorithms), Travis Downs (performance archaeology),
Peter Cordes (his Stack Overflow x86 answers are a reference work in their own right,
and the x86 tag wiki he maintains is genuinely excellent), Fabian Giesen (ryg),
Anger's forum, stuffedcow.net (Henry Wong, branch prediction), and the
highload.fun / Algorithmica (en.algorithmica.org/hpc) performance material.
§19. Quick Reference¶
19.1 Numbers to memorize¶
- Cache line: 64 bytes.
- Latency: L1 ~4, L2 ~12, L3 ~40, DRAM ~200–300+ cycles.
- Branch mispredict: ~15–20 cycles.
- Integer divide: 20–100 cycles (strength-reduce it).
- Stack alignment at a call: 16 bytes on x86-64 SysV, AArch64, and RISC-V.
- x86-64 GPRs: 16 (32 with APX). AArch64: 31 + zero. RISC-V: 32 (x0 = zero).
- x86 instruction length: 1–15 bytes. AArch64 and RV: fixed 32-bit (RV
C: 16). - System V red zone: 128 bytes. Windows shadow space: 32 bytes.
19.2 First moves¶
| Task | Do this |
|---|---|
| Understand what the compiler did | godbolt.org, -O2 -masm=intel |
| Find the hot instruction | perf record → perf annotate |
| Look up latency/throughput | Agner Fog's tables; uops.info |
| Analyze a loop statically | llvm-mca, uiCA |
| Check ABI compliance | Poison callee-saved registers and verify after the call |
| Debug at instruction level | gdb: layout asm, si, info registers |
| Verify a hand-written routine | Random differential test vs. a C reference |
| Check for a CPU feature | CPUID (x86) / getauxval(AT_HWCAP) (Linux ARM/RV) |
19.3 Hand-written assembly review checklist¶
- [ ] Correct ABI: arg registers, return register, callee-saved preserved
- [ ] Stack 16-byte aligned at every call; no red-zone use in kernel/interrupt context
- [ ] CFI directives present, and
.type/.sizeset - [ ] Tail/remainder path tested (this is where SIMD bugs live)
- [ ] Unaligned and zero-length inputs tested
- [ ] Memory barriers correct for the weakest target, not just x86
- [ ]
vzeroupperbefore returning from AVX code - [ ] Runtime feature detection, with a fallback path
- [ ] For crypto: no secret-dependent branches, no secret-dependent addresses, no variable-latency ops on secrets — and a DIT/DOIT/Zkt story
- [ ] Differential-tested against a reference implementation
- [ ] Benchmarked on more than one microarchitecture
§20. Sources and Method¶
Method. Narrative (not systematic) review. The durable material — §1 → assembly-fundamentals-and-isas (machine model),
§6 → assembly-toolchain-performance-and-simd (ABIs), §8 → assembly-toolchain-performance-and-simd (reading disassembly), §9 → assembly-toolchain-performance-and-simd (performance fundamentals), §10.4 → assembly-toolchain-performance-and-simd, §11 → assembly-systems-crypto-and-inline, §12.1 → assembly-systems-crypto-and-inline,
§13.2 → assembly-systems-crypto-and-inline, §14 → assembly-systems-crypto-and-inline, §15 — is synthesized from the vendor architecture manuals, the optimization
references in §18, and long-established practice. Every time-sensitive claim (ISA
extension status, profile contents, constant-time guarantees, silicon deployment) was
verified against a primary or near-primary source in August 2026 and is flagged in
§17 with a decay-risk rating. Where practitioners genuinely disagree — mostly about how
much hand-written assembly is justified — §16 presents both cases.
Search log (August 2026): Intel APX and AVX10/AVX10.2 status and Nova Lake support · RISC-V RVA23 profile ratification and mandatory extensions · constant-time programming, Intel DOIT and Arm DIT · Armv9, SVE2, SME/SME2 and Apple Silicon deployment.
Primary and near-primary sources consulted (selected):
- Intel — Architecture Instruction Set Extensions and Future Features programming
reference (rev 060, November 2025), the AVX10 architecture specification, and the
Data Operand Independent Timing ISA Guidance and timing-side-channel guidance articles
- RISC-V International — RVA23 ratification announcement (21 Oct 2024), the Ratified
Specifications Library (docs.riscv.org/reference/rva23), and riscv/riscv-profiles
rva23-profile.adoc for the mandatory/optional extension lists
- Arm — the Armv9-A architecture page; DIT register documentation
- TechInsights on APX's register and load/store impact; Phoronix, TechPowerUp,
VideoCardz, and igor'sLAB on the Nova Lake ISA confirmation; the LKVM/KVM
AVX10.2 CPUID patch series for the AVX10/512 policy change
- Academic and practitioner security work — "Let's DOIT: Using Intel's Extended HW/SW
Contract for Secure Compilation of Crypto Code" (TCHES 2025), "Constant-Time Code: The
Pessimist Case" (IACR ePrint 2025/435), "Constant-Time Wasmtime, for Real This Time",
LWN.net's "Constant-time instructions and processor optimizations", and the oss-sec
thread on data-operand-dependent timing
- Trail of Bits on LLVM constant-time intrinsics; academic SME benchmarking work on
Apple M4 confirming Armv9.2-A, SME and SME2
Confidence statement. High confidence in §1–§14 → assembly-fundamentals-and-isas, assembly-systems-crypto-and-inline and §19 — these rest on vendor
architecture manuals, ABI specifications, and long-established optimization literature.
High confidence in §17's RISC-V RVA23 contents and the DOIT/DIT descriptions, which
come from the ratified specification and vendor documentation respectively. Moderate
confidence in the Nova Lake and AVX10/APX shipping details: they come from Intel's own
ISA reference manual (a primary source) but describe unreleased hardware, and this
specific question had contradictory reporting through late 2025 before the manual settled
it — treat ship dates and final feature lists as subject to change. Moderate confidence
in §10.3 → assembly-toolchain-performance-and-simd's SME deployment picture, which is assembled from vendor announcements,
academic benchmarking, and trade reporting rather than a single authoritative source;
the direction (uneven, runtime-detect) is reliable, the per-vendor specifics less so.
Cycle-count figures throughout §9 → assembly-toolchain-performance-and-simd and §19.1 are order-of-magnitude guidance across
typical modern cores, not measurements for any specific microarchitecture — use Agner
Fog's tables or uops.info for real numbers.
Plugin: assembly-programming · View SKILL.md on GitHub