pub enum Stepping {
Fixed,
Early,
}Expand description
Which VR4300 stepping a console carries.
The only behavior that currently depends on it is the FP multiplication
erratum, and that dependency is why this is modeled as console state
rather than folded into mul: an unconditional erratum would make every
multiply on every console wrong, and most consoles do not have it.
Variants§
Fixed
A later stepping, with the multiplication erratum fixed.
The default, because it is the majority of hardware and because the
erratum’s output is undocumented — see Stepping::has_mul_erratum.
Early
An early stepping carrying the erratum: NUS-01 and NUS-02 (Japan only) and NUS-03 (the first US revision).
Implementations§
Source§impl Stepping
impl Stepping
Sourcepub const fn has_mul_erratum(self) -> bool
pub const fn has_mul_erratum(self) -> bool
Does this stepping carry the FP multiplication erratum?
§Why the erratum is not implemented
The trigger is documented (n64brew_wiki/markdown/VR4300.md): a
multiply whose preceding multiply had a NaN, zero or infinity operand
“may produce unexpected results”. GCC’s -mfix4300 works around it by
inserting two nops after every MUL.S/MUL.D/MULT.
What the corrupted output actually is has never been characterized —
our own ref-docs/2026-07-20-vr4300-timing-supplement.md lists it under
undocumented constants, with only trigger conditions known. So the
erratum can be detected here but not reproduced, and inventing a
plausible wrong value would be exactly the fitted-constant failure
docs/accuracy-ledger.md forbids: every later result built on it would
stop being evidence.
Accuracy-ledger U-7. Selecting Stepping::Early therefore changes
nothing yet — it exists so that when the output is characterized, the
switch is already in the right place rather than threaded through
afterwards.