FP hardware survey — fleet capture campaign (tracking)
- Dominant language
- C++
- Stars
- 2
- Forks
- 8
- PR merge metrics
- No merged PRs in 30d
Description
# FP hardware survey — fleet capture campaign
Coordinates the cross-machine floating-point hardware survey produced by
`crates/fp-hw-survey`. The tool captures native scalar FP results + exception
flags through per-architecture inline asm (not libcore math), then `merge`s
captures from many machines to surface the rows where hardware actually
disagrees. See `crates/fp-hw-survey/README.md` → **Collecting captures across
the fleet**.
## Why this campaign
- **Confirm intra-ARMv8 determinism.** The Arm ARM defines `frecpe`/`frsqrte`/
`frecpx`/`fmulx` via exact pseudocode; distinct ARMv8 vendors *should* produce
bit-identical estimates. A **zero-divergence** merge across AArch64 machines is
the expected, informative result — positive confirmation of conformance.
- **Map the genuinely divergent axes.** Cross-architecture x86-64 ↔ AArch64
semantics (`fmax`/`fmin` NaN handling, float→int saturation, flush-to-zero
edges), and any single-precision estimate difference attributable to a
`FEAT_RPRES` / `FPCR.AH` context gap (`rpres`/`afp` are recorded in each
capture header precisely so such a row is read as a feature difference, not an
erratum).
## Target SKUs
- [ ] Apple Silicon (M-series, arm64/macOS) — #166
- [ ] Snapdragon X-series (arm64/Windows-on-ARM) — #167
- [ ] Ampere Altra / AWS Graviton (arm64/Linux) — #168
- [ ] x86-64 baseline (Intel + AMD) — #169
## Acquisition (manual, per machine)
No CI capture job — the interesting SKUs are physical hardware a hosted runner
does not represent. Each machine owner builds `--release`, runs `info` +
`selftest` (capture refuses to write if the self-test fails), then `capture
--label `, and submits the NDJSON plus the one-line header on the
matching per-SKU issue above.
## Ingest (offline, on one machine)
```sh
fp-hw-survey merge --out divergences.ndjson capture-*.ndjson
```
Commit **only**, never the raw multi-hundred-MB captures:
- **`divergences.ndjson`** — the merge output (expected *empty* for intra-ARMv8
estimate ops; an empty file is the positive result).
- a **provenance table** — one row per contributing capture copied from its
header: `label`, `cpu`, `os`, `features`, `captured_utc`, row count,
`tool_version`.
Raw captures are retained out-of-band (issue attachments / artifact storage).
## Close-out
Paste the `merge` stderr summary (machine count, aligned-key count, divergence
count, per-op breakdown) into this issue and check off the contributing SKUs
above.
Contributor guide
No contributing guide indexed for this repository
Research direction
Start with crates/fp-hw-survey/README.md, especially “Collecting captures across the fleet,” then build --release and run info, selftest, and capture on an available target machine. Submit the NDJSON and header to the matching SKU issue, then run fp-hw-survey merge and record divergences.ndjson, the provenance table, and the stderr summary here.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust
- Domain
- embedded-iot
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Clearly specified
- Newbie friendliness
- 35/100