Since 1996, Danish programmer Agner Fog has measured x86 instruction execution latencies one instruction at a time, publishing the results as tables. His work fills the gap between the figures Intel and AMD officially publish and real-world measurements, and has become the de facto standard reference that compiler developers and assembly programmers consult when trying to shave off even a single cycle. The direction of this field has always been consistent: make things faster.
On August 7, 2026, Christopher Domas rotated that vector 180 degrees. He published a GitHub repository called "asm-hall-of-shame" (Assembly Hall of Shame) and launched a leaderboard for finding the "slowest single x86 instruction." On X (formerly Twitter), Domas declared: "Everyone else is trying to make CPUs fast. I'm trying to break them."
How a 150-Cycle Instruction Turned Into 198 Billion Cycles
The current champion is fxrstor64. This instruction restores FPU, MMX, and XMM register state along with MXCSR from a 512-byte region in memory. Intel's reference documentation lists a typical latency of about 150 cycles. In Domas's hands, that same instruction took 198,002,498,236 cycles — 62 seconds of wall-clock time. That's roughly a 1.32-billion-fold slowdown.
The technique consists of three stages.
Stage one. Domas used his own tool, mmiotic, to locate high-latency MMIO (Memory-Mapped I/O) regions inside the PCIe fabric. MMIO is the mechanism by which the CPU accesses peripheral device registers as part of its memory address space. MMIO reads over PCIe are orders of magnitude slower than DRAM accesses. Domas exploited this inherent slowness by pointing fxrstor64's read target at that MMIO region. The 512 bytes of state data then had to pass through the slowest possible memory aperture. This alone produced 74,584,168,512 cycles (about 23.4 seconds).
Stage two. While the fxrstor64 read is in flight, a separate group of cores fires off rapid-fire 4-byte reads against other high-latency MMIO registers. This saturates the PCIe root complex with non-posted transactions, causing fxrstor64's 512-byte read to get queued behind a pile of meaningless read operations. The result: 198,002,498,236 cycles (62 seconds) — roughly 2.65 times slower than stage one alone.
| Condition | Cycle Count | Wall-Clock Time | Multiplier vs. Normal |
|---|---|---|---|
| fxrstor64 normal execution (Intel reference) | ~150 | tens of nanoseconds | 1× |
| fxrstor64 + high-latency MMIO | 74,584,168,512 | 23.4 sec | ~500 million× |
| fxrstor64 + MMIO + fabric starvation | 198,002,498,236 | 62 sec | ~1.32 billion× |
| (Planned) xrstor64 + AMX 8KB state region | over 1,000,000,000,000 (projected) | over ~5 min | ~6.7 billion× |
As a third stage, Domas has his eye on xrstor64 using AMX (Advanced Matrix Extensions), available since Intel Sapphire Rapids. Since the state region expands 16-fold from 512 bytes to 8KB, Domas expects to exceed one trillion cycles.
When a "Slow Instruction" Breaks Security
What keeps this project from being dismissed as mere curiosity is another repository Domas published simultaneously: "smiiiiiiiiiiiiiiii."
x86 CPUs feature a privileged execution environment called SMM (System Management Mode) — a top-privilege mode invisible even to the OS or hypervisor, responsible for firmware-level power management and hardware error handling. SMM's security model rests on one assumption: when one core enters SMM, all other cores enter SMM simultaneously (a rendezvous). While SMM is executing, no core is supposed to be running outside it.
What happens if that assumption breaks down? Over 100 reported vulnerabilities fall into the TOCTOU (Time-of-Check to Time-of-Use) category, where an SMM handler checks a value in shared memory and then uses it. These have traditionally been dismissed as effectively unexploitable, on the assumption that rewriting memory during SMM execution requires physical access from a DMA-capable peripheral.
Domas's experiment demonstrates that this assumption can be broken using software alone. If you tie up a single core with an extremely long single instruction (more than one second), that core cannot participate in the SMM rendezvous. Once SMM's timeout (roughly one second) elapses, the other cores continue executing inside SMM while the tied-up core keeps running in normal mode. SMM's "exclusivity" collapses.
In Domas's PoC, running on an AMD Ryzen 7 5800H, a high-latency MMIO read via the vmovdqu instruction was used to observe SMI counter divergence — that is, one core's SMI count failing to match the others'. This is direct evidence that a core continued executing outside SMM.
Rules of the Anti-Optimization Contest and the Measurement Environment
The leaderboard has clear rules. Only the execution of a single instruction counts toward the score. Any setup is permitted, but only one instruction's worth of time is measured. Interruptible instructions (such as rep movs or pause) are disqualified. For trapped instructions, only the trap itself is timed; time spent inside the handler doesn't count. Time is normalized to CPU base clock, and hardware must be used in its factory-default state.
The primary test platforms are an AMD Ryzen 7 5800H (inside a Trigkey S5 mini PC) and an Intel Core i7-8559U. For testing the rdmsr instruction, a VIA Eden chip (an early-2000s embedded processor) was used. VIA chips contain an undocumented register, 0x133, against which rdmsr reportedly returns an abnormally long response time of 202 microseconds (161,602 cycles).
| Rank | Instruction | Strategy Summary | Score |
|---|---|---|---|
| 1 | fxrstor64 | MMIO + fabric starvation | 198,002,498,236 cycles |
| 2 | fxrstor64 (baseline) | MMIO read only | 74,584,168,512 cycles |
| 3 | vmovdqu ymm (unaligned) | spec-violating unaligned 32-byte read | 443,937,696 cycles |
| 4 | vmovdqu ymm | 32-byte MMIO read | (below 3rd) |
| 5 | vmovdqu xmm | 16-byte MMIO read | (below 4th) |
| 6 | mov rax | 8-byte MMIO read | (below 5th) |
| 7 | mov | 4-byte MMIO read | (below 6th) |
The third-place entry, vmovdqu ymm (unaligned), is particularly interesting. Issuing a 32-byte read against an unaligned address causes it to split into nine separate dword register accesses. This is technically forbidden by the specification, but the CPU executes it anyway. Domas directly repurposed this spec-violating instruction for the SMM attack described above.
The Lineage of a Researcher Named Domas
Domas describes himself as a security researcher devoted to "impractical solutions to nonexistent problems." He worked at Battelle Memorial Institute (2009 to 2018) and then Intel (2018 to 2025) before going independent. His previous notable works include movfuscator, which compiles arbitrary C programs using only mov instructions (10,190 GitHub stars); sandsifter, which systematically discovers undocumented x86 processor instructions (presented at Black Hat 2017); and rosenbridge, which exposed hardware backdoors in x86 CPUs (Black Hat 2018).
sandsifter took the approach of "breaking the instruction set," uncovering millions of instructions not officially acknowledged by processors. Assembly Hall of Shame applies that same motivation — probing the boundaries of the ISA — but points it in the opposite direction along the speed axis.
Untested Conditions and Remaining Questions
ARM and RISC-V versions of the leaderboard are planned but currently marked "T.B.D." Since MMIO ordering rules differ across architectures, it's unclear whether the top-ranked strategies would even work there. On Hacker News, some have argued that "using MMIO is cheating and makes the results boring — the competition should be limited to main memory." But Domas's rules don't prohibit MMIO.
Another open question is whether there's an upper bound on this kind of delay. If a PCIe bus can be stalled for an arbitrary length of time, there may be no theoretical ceiling on fxrstor64's latency at all. In the GitHub README, Domas himself names extending to the 8KB AMX state region as his "next target" — though this can't be verified without access to a Sapphire Rapids or later CPU.
As for the SMM attack, the PoC has so far only been tuned for a single Zen 3 machine. In the README, Domas writes: "On your platform, you'll need to rediscover high-latency MMIO addresses using mmiotic, then progressively widen the instruction from xmm to ymm to zmm until you exceed the rendezvous timeout." Generalizing the exploit requires per-platform tuning.
Even so, the fact this research has surfaced is significant. In a space where CPU designers have implicitly assumed that "a single instruction finishes within a few cycles," there exists an instruction that can sit motionless for 62 seconds. And a security model built atop that assumption can be broken by a single line of assembly.