nx_f32_hw.nx

nx_f32_hw.nx -- HARDWARE IEEE-754 f32 for NishiLang via the __f32_* compiler intrinsics (R1b -> SSE scalar-single on the CPU FPU). Distinct from nx_f32.nx, which is the i64 SOFT-FLOAT emulation of the same binary32 -- IDENTICAL bit layout (binary32 in the low 32 of an i64), so the two are bit-for-bit cross-checkable (see nx_f32_vec_gate differential). This is the FAST reusable MATH PART the sovereign renderer composes: scalar + vec3 now, mat4 next. negate = x * -1.0f (subss deferred to a perf rung). license_tier: ORIGINAL ===== DO NOT COLLAPSE THESE TWO MODULES INTO ONE (2026-08-23) =============== A tempting "optimisation" is to re-point nx_f32.nx's BODIES at the __f32_* intrinsics, so every existing nx_f32_* caller gets the hardware path for free. THAT WOULD DELETE AN ORACLE, and it was measured and refused this session: nx_f32.nx is an INDEPENDENT IEEE-754 implementation. It is the only thing in the estate that proves this hardware path is CONFORMANT rather than merely SELF-CONSISTENT. If the soft-float BECOMES the intrinsic, nx_f32_vec_gate's differential compares the hardware path AGAINST ITSELF -- every agreement goes vacuous and the estate loses its only independent check on its own float backend. A slow reference whose only remaining job is to DISAGREE with the fast one is doing the most valuable job in the codebase. The differential was measured exhaustively over every IEEE class (16x16 = 256 pairs, _offc_probe_f32equiv.nx): 254 agree BIT-FOR-BIT -- including the rounding-sensitive 1.0+2^-24 / 1.0+2^-23 and the subnormals, which REFUTES any double-rounding-through-f64 hazard -- and exactly 2 differ: inf + (-inf) yields a NaN whose SIGN BIT differs (soft-float returns a fixed POSITIVE qNaN, x86 its default NEGATIVE qNaN). IEEE-754 does not specify the sign of a NaN result, so neither is wrong. Both estate routes for observing a NaN are structurally blind to it anyway: nx_f32_classify reads only exponent+mantissa, and nx_f32_eq returns 0 for any NaN before it ever compares bits. SO: THIS IS THE FAST PATH, AND IT IS THE ONE HOT CODE SHOULD CALL. want speed -> f32_add / f32_mul / f32_div (here; one SSE instruction) want the reference oracle -> nx_f32_add / nx_f32_mul / ... (nx_f32.nx) Migrating a hot consumer from nx_f32_* to f32_* is a REVIEWABLE PER-CONSUMER decision that keeps the oracle intact. nx_f32_vec_gate's anti-vacuity tooth enforces this: collapsing the two paths turns it RED (bite-proven, exit 35). ============================================================================