Initialize guest floating-point state explicitly

[N7Alpha]

It looks like you need to set a flag in a control register at least on my M4 MacBook Air. My only validation is this fixed an issue in a vibe code decomp I had for 7 functions. Late in the decomp I wanted to switch to this project from Wine because I was losing my mind with Wine, but I lost 7 matched functions. GPT 5.6 root-caused the fix and matched all 7 wibo with no regressions on >3200 functions.

GPT 5.6

Bug

wibo inherited the host thread's floating-point environment when entering a Win32 guest. On macOS under Rosetta, the x87 control word was 0x037f, which selects 64-bit extended precision. Win32 processes and threads start with 0x027f, which selects 53-bit precision.

This changed an internal optimizer comparison in Metrowerks mwccarm.exe. The compiler consequently emitted a semantically equivalent switch comparison tree in a different order, preventing byte-identical reproduction of ARM objects that match the original ROM under Wine.

Root cause

The x87 precision-control bit was the causal hidden-state difference. Immediately before guest entry, wibo reported 0x037f. Loading only 0x027f—without changing heap placement, allocation contents, or MXCSR—made the canonical Wine and wibo objects byte-identical.

Fix

Initialize the floating-point environment whenever a TIB is installed for a guest thread:

• reset the x87 unit;
• load the Win32 x87 control word 0x027f;
• load the default MXCSR control state 0x1f80.

Doing this in per-thread setup covers the initial executable, DLL/TLS callbacks, and threads created through CreateThread.

A new fixture captures floating-point state from a process-attach TLS callback and a created thread. It checks exact x87 control state and the MXCSR control bits while allowing exception status flags that may be raised during loader work.

[encounter]

Thanks! I verified this as a bug and rewrote it to match the existing codebase style.