VFP floating-point: remaining f32 pseudo-ops and f64 support

[avrabe]

Context

PR #41 implemented VFP single-precision (f32) instruction encoding for cortex-m4f targets. This issue tracks the remaining floating-point work.

Remaining f32 work

The following f32 operations return errors and need implementation:

• f32.ceil — needs ARMv8-M VRINTA or software fallback
• f32.floor — needs ARMv8-M VRINTM or software fallback
• f32.trunc — needs ARMv8-M VRINTZ or software fallback
• f32.nearest — needs ARMv8-M VRINTN or software fallback
• f32.min — needs VCMP + branch or ARMv8-M VMINNM
• f32.max — needs VCMP + branch or ARMv8-M VMAXNM
• f32.copysign — bit manipulation (VABS + sign extract + OR)

Options

1. ARMv8-M path: Use VRINT* instructions (only on ARMv8-M cores like Cortex-M33)
2. Software fallback: Implement via VCMP + branch sequences (works on all VFP targets)
3. Kiln delegation: Route these to the interpreter (current mixed-mode approach)

F64 (double-precision) support

Currently all f64 ops are correctly rejected. Double-precision VFP (VFPv5-D16) is available on cortex-m7 targets. This would need:

• FPUPrecision::Double target profile
• D-register (D0-D15) allocation
• VFP double-precision encoding (.F64 variants)
• 64-bit load/store via VLDR.64/VSTR.64

VFP register allocation

Current allocation is linear wrapping (S0-S15). Future work:

• Liveness-aware VFP register allocation
• Spill/reload to stack for register pressure

🤖 Generated with Claude Code