nx_f64_gate.nx

nx_f64_gate.nx -- LN16 "WORKING f64 ARITHMETIC": the x86_64 backend's IEEE-754 binary64 arithmetic AND ordering, measured BIT FOR BIT against independent software implementations of the same standard. WHAT THIS MEASURES THAT THE INCUMBENT CANNOT. nx_f64_adversary (T12, shipped 2026-07-16) is a DECIMAL instrument: every check truncates a scaled product to six or nine digits and compares a hand-typed integer. That shape cannot see a one-ulp error, cannot say WHICH bit moved, and asks the reader to take six magic constants on trust. It also compares only NON-NEGATIVE values, which is why it never found the ordering defect this gate reports. Every expectation here is DERIVED at run time from nx_f64_oracle_sov (orc_add/orc_sub/orc_mul/ orc_div) and nx_f64 (nx_f64_lt/gt/eq) -- pure-integer implementations whose anchor proof is the 1217 hardware-IEEE KAT values in _f64_soak_gate_authored. There is not one hand-typed floating-point constant in this file, and operand bit patterns come from nx_i64_to_f64, a THIRD path, so an operand and its expectation are never produced by the same code. WHY BITS AND NOT PRINTED DECIMALS. Two doubles one ulp apart print identically at nine significant digits. The defect this rung exists to remove -- f64 arithmetic silently executed at single precision -- is a low-mantissa error, so a decimal comparison is precisely the instrument that cannot see the end of it. WHY ORDERING IS IN SCOPE. A double rides in an i64 register, and x86ctx_emit_cmp lowers EVERY compare to a signed integer cmpq on those bits. Among two negative doubles the signed-integer order is the REVERSE of the numeric order, so `-1.0 < -2.0` evaluates TRUE. The rung's own done-rule program compares two f64 values, so ordering is already inside the capability the row claims; flipping the row while `<` is inverted would publish a capability that is not there. Tooth `neg-control-chosen-negative-pair-is-exactly-where-integer-compare-fails` proves the operands chosen are the discriminating ones and not a lucky pair. HOW A FIXTURE REPORTS. A wait status carries eight bits of exit code. A value fixture returns 0 when the bits matched and F6_EXITBASE + k when the HIGHEST differing bit is k (2..65, inside 255), so a failure NAMES the field that moved: 63 sign, 52..62 exponent, 0..51 significand. A predicate fixture returns F6_EXITBASE + the boolean the compiler actually produced, so a failure says which way it went. A pass/fail bit would have said only "wrong". HOW THE BITS ARE READ. NishiLang carries an f64 in an i64 register and `as` is a BIT-REINTERPRET, never a value conversion -- only the __f64_to_i64 intrinsic