Hojun-Cho
263257f2c1
Ports the subnormal-normalize step of the f64 decompose half from ref/hare/math/floats.ha: issubnormalf64 (floats.ha:179) and normalizef64 (floats.ha:256, the f64-multiply-on-subnormal that yields (f64, i64)). frexpf64 (floats.ha:278) is held back, not ported: its Hare-exact zero guard `n == 0f64` miscompiles. A no-decimal `0f64` literal used as an f64 comparison operand is materialized into a GPR and never moved to XMM, so the UCOMISD reads a stale operand and `n == 0f64` is wrong for every n. Both stages emit this identically, so the byte-id gates are blind to it. `0.0` compiles correctly but substituting it would be a workaround (rule 7), so frexpf64 waits for the cgen fix. normalizef64/issubnormalf64 touch neither the broken literal form nor any tuple-field comparison, so they are correct and land now.