# A ported fixed-point function differs from the original in a few cases out of thousands

## Symptoms

A port of a 16.16 routine agrees with the original almost always, and differs in a handful
of cases when both are run on many inputs. In POD the gate test (`FUN_0042a1f0`, which
decides whether a car crossed a lap line or checkpoint) differed in 15 of 20,000 moves
between a floor model and a round-to-nearest model, all with a point within a hair of the
gate's plane.

## Cause

The routine converts a float sum to an integer with the "magic number" trick: `fadd` of a
large constant, `fstp` to a double, then read the double's low word. In POD's dot product
(`FUN_004db530`) the constant at `0x4fa000` is 1.5 × 2^68, so the low word holds the sum
divided by 65536: a 16.16 result. The division's rounding is the FPU's current mode, and
with the x87 at 64-bit precision it rounds twice: each `fadd` to a step of 32 (the
constant is added to the *first* product, then the others one by one), then the store to a
double to a step of 65536 (*observed* in the instructions; *measured* below).

## Evidence

The original run under Unicorn (`measure/race_rules.py`) with a small stub that loads a
chosen control word (`fninit; fldcw [cw]; call FUNC; hlt`), on the track's own gates and
points placed near each plane. Each control word needs its own model: under 0x037f (64-bit)
each sum rounds to a step of 32 first; under 0x027f (53-bit) straight to a step of 65536;
under 0x0f7f the sums are floored. Each model matched all 20,000 cases under its own word.
Which word the game uses had to be measured in the running game: POD races with 0x027f
(pod-physics' step log reads it each step), not the 0x037f its C library's start-up leaves.
On POD Gold's gate test the words differ in 11 (0x027f against 0x037f) and 20 (against
truncation) of 20,000 cases.

## What to do

Model the conversion exactly in integers: keep the magic constant, add each product in the
order the code does, round each `fadd` to the precision the control word sets, then to the
double's step, and subtract the constant (`crates/pod-race/src/gate.rs`, `dot`). Then read
the control word in the running game (a hook or a step log; the C library's start-up word
is not enough: POD's changes after it), and measure the function under that word. Keep the
measurement as the port's test.

`pe32_emu`'s `emu.fpu_modes(FUNC, cases, cws=(0x037f, 0x027f, 0x0f7f))` runs a routine under
each control word and lists the cases whose result differs; `call(..., fpu_cw=...)` runs it
under one.

## Tried

- A floor model (from an earlier, wrong reading that the game ran truncated): 15 of 20,000
  wrong under round to nearest.
- A 64-bit model (from the start-up's `fninit`): right under 0x037f, but the game races with
  0x027f; corrected on Gold.
- Rounding the exact sum once: matched these 20,000 cases too, but differs from the x87
  wherever the 64-bit step of a partial sum lands on a tie; the sequential model is the
  instruction's own.