According to a post on the flat assembler forum, a developer working on console-rendering code discovered what appears to be an AMD-specific quirk: the hardware random-number instructions rdrand and rdseed seem unable to produce a zero value at a given bit width. The same test, run on an Intel processor, produces zeros without issue. The report is a single user's observation, not a confirmed defect, and the author is careful to frame it as something to verify rather than a bug declaration. The post carries 101 points and 51 comments, which gives it some traction but no vendor response.

The mechanism hinges on how the CPU's hardware RNG fills the register. The user's test application renders a bar graph across the full 16-bit space, counting how often each value appears. On an AMD host, the bar representing zero never changes from its initial state, and the chart's base never scales up from zero. On Intel, the zero bar moves and the base extends past zero. The user notes the test requires a specific macro kit to compile as-is, and that switching rdrand and rdseed to 32-bit or 64-bit registers while keeping 16-bit display data changes the behavior, which points to the register width as the variable. The chart also renders the other 65,535 values from the 16-bit space, so the zero-absence is isolated to the lowest value.

Versus the status quo, this would be a divergence in how two major CPU vendors implement their hardware RNG instructions. Intel's rdrand is documented to produce a full range of values including zero. If AMD's implementation systematically excludes zero at certain widths, that would be an unusual constraint on a primitive that developers rely on for seeding and entropy. The post suggests the issue may be limited to a specific generation, possibly Zen 2, though the author is not certain which silicon exhibits it, and the title itself flags the question mark.

What is unconfirmed: no AMD statement, no reproduction by other users, and no independent test. The behavior could be a genuine implementation gap, a misunderstanding of the instruction's semantics at narrow widths, or an artifact of the specific test harness. The forum thread has comments, but nothing in the report indicates a definitive resolution or a vendor response, and the author invites others to run the attached test on their own hardware.

What to watch next: whether other developers reproduce the zero-absence on AMD hardware, whether AMD's engineering team comments on the instruction's behavior at narrow widths, and whether the result changes when the register width is widened. A confirmed, reproducible gap would matter for anyone relying on rdrand for entropy or for seeding downstream randomness, and it would be an unusual footnote in the comparison of the two vendors' RNG primitives.