There's a particular kind of detective story that only happens at the hardware-software boundary, where documentation is supposed to be gospel and opcodes are supposed to be ground truth. This is one of those stories, and it's a good one. The instruction vfmaddrnd231pd appears in Intel's Software Development Manual with full documentation — pseudocode, encoding tables, a unique immediate byte controlling per-instruction rounding modes. It's not a typo or a stray reference. Someone at Intel wrote detailed specification text for an instruction that would let developers control rounding behavior on a per-operation basis without touching the slow global rounding-mode register, and without requiring AVX-512. For algorithms that depend on rounding — interval arithmetic, compensated summation, reproducible floating-point — this would be a meaningful capability. Except: GNU assembler doesn't recognize it. The intrinsics Intel's own manual references (mmfmaddroundpd, mm256fmaddroundpd) don't exist in Clang or even in Intel's own ICC compiler. The VEX encoding uses a "DDS" field that appears nowhere else in the entire SDM and was apparently removed from later editions. And when the author hand-assembled the opcode and ran it on a Haswell CPU — which supports the FMA instruction set this supposedly belongs to — the processor raised #UD, the "undefined instruction" exception. The mystery deepens with a version comparison. The instruction is present in the 2024 SDM but absent from the 2026 edition. It was silently removed. No errata notice, no explanation, no public acknowledgment. The author also notes that only the 231pd variant was ever documented — real FMA instructions come in pd/ps/sd/ss and 132/213/231 variants, suggesting whatever this was, it never reached the stage of full variant expansion. The author's best hypothesis is plausible and elegant: Intel planned the vfmaddrnd instruction family, found a late-stage issue (silicon bug, microarchitectural conflict, validation failure), pulled it from the CPU, but didn't fully scrub the documentation. The detailed pseudocode and unique tables suggest real engineering effort, not a placeholder. Something was built, or at least designed to completion, and then abandoned. What makes this piece work as writing is the forensic methodology. The author doesn't speculate first — they systematically try every verification path (assembler, compiler intrinsics, opcode encoding, hardware execution, cross-version comparison) before reaching a conclusion. Each dead end narrows the hypothesis space. It's a template for how to investigate documentation anomalies at the ISA level. The piece closes with an open call: if anyone has a contact at Intel, the author wants the real answer. That's the right ending. Some mysteries in computing have prosaic explanations that only someone inside the organization can provide. Until then, vfmaddrnd231pd remains a ghost instruction — fully specified, never instantiated, quietly buried.
