test(qemu): measure allocator discipline and footprint vs lru

[ddsha441981]

Follow-up to #21. That PR proved the crate runs on Cortex-M0. This one measures the two things an embedded reviewer would push back on, both of which were unmeasured prose until now. No new CI infrastructure — both land in the QEMU job #21 added.

1. "It needs an allocator"

True, and unavoidable — PulseMapRaw::new builds Vecs (src/raw.rs:60) and there is no const-generic or caller-storage constructor. But when it needs one is the part that decides whether firmware can use it, and that is measurable. The bump allocator in qemu-test/ now counts its calls:

Map	Allocations at new()	Allocations during 256 insert+get+remove
TypedPulseMap<u32, u32> (inline)	2	0
TypedPulseMap<u64, u64> (slab)	2	14 per 6 inserts

The two are buckets and slots_ttl. Inline mode never allocates again, so a fixed buckets × 128-byte arena lasts the map's whole lifetime — "needs a heap" (a dealbreaker in firmware that deliberately has none) becomes "needs a static arena at init" (a line in main). Both rows are checked assertions in the QEMU test, so they cannot silently stop being true.

The second row is the counterexample, reported rather than hidden: u64 exceeds the 6-byte key / 7-byte value inline window (src/engine/slot.rs:53), entries reach the slab, and SlabPool grows via push (src/engine/slab.rs:122,130). A static arena is not sufficient there.

2. "How big is it, really?"

Three probe binaries under qemu-test/src/bin/ plus size.sh, comparing against lru — the only other cache in the README's table that builds without std, so the whole field on bare metal. Same workload, same target, same profile, both holding 64 resident entries (len is printed, not assumed).

Emulated Cortex-M0 (thumbv6m, --features m0), figures as CI prints them:

	Flash over baseline	RAM	Allocations
PulseMap	7,320 B	2,048 B — 32 B/entry	2
lru	7,176 B	4,520 B — 70.6 B/entry	68

Same 64 entries in 55% less RAM, touching the allocator twice instead of 68 times. Flash is a wash: 144 bytes apart, 2.0%.

Reported against interest. On Cortex-M3 the flash comparison inverts and it is not close — PulseMap 9,792 B to lru's 7,576 B. portable-atomic's spinlock AtomicU64 fallback is fatter than the critical-section route M0 takes. Where flash is the binding constraint on an M3-class part, lru is the smaller choice, and the README now says exactly that.

Why there is a third binary

footprint_none has no cache at all and is subtracted out. Without it the table is mostly measuring hprintln!, semihosting and the panic handler — 2,496 B of the thumbv6m total. Host binutils size reads ARM ELF, so no arm-none-eabi toolchain is needed; size.sh skips with a message if size is absent rather than failing the job.

Two corrections made while measuring

LTO. The first measurement had qemu-test on the default release profile, which has LTO off — the parent crate's lto = true doesn't cross a workspace boundary. That put PulseMap at 10,556 B vs lru's 6,672 B, a 58% gap that was measuring un-inlined cross-crate glue nobody flashes. With lto = true + codegen-units = 1, matching the parent and matching what real firmware ships, the M0 gap closes to 2%.

Toolchain. Flash figures are quoted from CI (stable rustc 1.98.1), not from a local build on 1.95.0, which printed ~50 bytes more per binary. Exact byte counts move between toolchain releases; the ratios don't, and the RAM and allocation counts don't move at all. Quoting CI means the source is one click from this PR.

Both are the kind of artifact that produces a confidently wrong table, so they are recorded rather than quietly fixed.

What is still not measured

No throughput or latency figure on any MCU, and the README now says so where it previously implied otherwise. QEMU is not cycle-accurate — no pipeline model, no flash wait states, no bus contention — so timing it would produce a number worth less than no number at all. Every performance figure in the docs is x86_64.

Closing that needs real silicon. An RP2040 is the honest choice, being the Cortex-M0+ part that actually needs critical-section; SysTick for cycles, same access pattern as the x86 bench, lru on the same board with the same allocator. Out of scope here.

Also unchanged from #21: riscv32imc stays compile-checked only, because qemu-system-riscv32 -machine virt has the A extension and would test a target that doesn't need the feature.

Notes

• No changes to src/. qemu-test/ remains its own workspace, and cargo package --list confirms it stays out of the publish tarball.
• Bump allocator extracted to qemu-test/src/bump.rs, shared by all four binaries; default-run added so cargo run is still unambiguous now that there are four.
• Footprint numbers are printed in CI, not gated — a size gate needs a stored baseline to diff against, which is a different PR.
• CHANGELOG appended under ## [Unreleased] — v0.6.5.