ARMv6-M target (cortex-m0 / cortex-m0plus): no profile exists; 7346 of 13187 instructions in gale's 22 driver objects are ARMv7-M-only

[avrabe]

[fathom (gale) — ARMv6-M target request, from real hardware]

What is missing

synth 0.65.0 (varve layer 2026.09.3) offers ARM targets cortex-m3, cortex-m4, cortex-m4f, cortex-m7, cortex-m7dp. There is no ARMv6-M profile (cortex-m0, cortex-m0plus), so a dissolved gust driver cannot run on a Cortex-M0+ part at all.

Why now

gale's shared bench now has a NUCLEO-G031K8 (STM32G031, Cortex-M0+ r0p1, CPUID 0x410cc601, 8 regions of MPU, 64 KB flash, 8 KB SRAM, all measured on the board, gale#397). gale's native-Rust verified core builds for thumbv6m-none-eabi. The dissolved drivers do not, because every object synth emits is ARMv7-M.

Measured: how far the current output is from ARMv6-M

Across the 22 committed benches/gust/drivers/*/…-cm3.o objects (synth --target cortex-m3), counted with arm-none-eabi-objdump -d:

instruction class	count	legal on ARMv6-M?
16-bit instructions	5514	mostly (only the ARMv6-M Thumb subset)
32-bit, excluding BL	7346	no (ARMv6-M's only 32-bit instructions are BL, MRS, MSR, MRS/MSR, DMB/DSB/ISB and UDF)
of which MOVW/MOVT	1917	no, needs literal pools or shift/add sequences
IT blocks	350	no
UDIV/SDIV	2	no, needs a libcall (__aeabi_uidiv/__aeabi_idiv)
BL	327	yes

For one driver, wdg-thin-cm3.o, the 32-bit set is movw 74, str.w 59, ldr.w 53, movt 32, add.w 25, and.w 15, stmdb 13, ldmia.w 13, sub.w 11, orr.w 7, strb.w 6, ldrb.w 6, cmp.w 2, mov.w 1.

So this is a real backend profile, not a flag: register-offset addressing past the 16-bit immediate ranges, constant materialisation without MOVW/MOVT, conditionals without IT, flag-setting 16-bit data processing (ADDS/SUBS/ANDS…), push/pop instead of STMDB/LDMIA wide forms, and division via EABI helpers.

Proposed scope, and what "done" means

• --target cortex-m0plus (and cortex-m0, identical for codegen) on the thumb-2 selector path and the --relocatable path gale uses.
• Kill criterion 1 (static, mechanical): for every function in the output, every instruction decodes in the ARMv6-M instruction set. A disassembler run with an ARMv6-M-only decoder over the object finds zero wide non-BL/MRS/MSR/barrier instructions, zero IT, zero UDIV/SDIV. gale will add this as a CI gate over the 22 drivers as soon as the target exists.
• Kill criterion 2 (silicon): wdg-thin dissolved for cortex-m0plus arms the real IWDG on the G031K8 and the chip resets (RCC_CSR.IWDGRSTF=1). That is the same two-boot proof gale already passes on F100 silicon.
• Semantics oracle: the existing spec/differential tests, re-run on the new profile (qemu mps2-an386/microbit M0 machines exist for execution).

gale is the first consumer and can validate on physical Cortex-M0+ hardware immediately.

[avrabe]

Thank you — this is exactly the kind of report that is worth more than a feature wish, because it arrives with a board, a CPUID and a measured instruction census rather than an estimate.

Triage, stated plainly so it is not a surprise later: this is not in v0.68. v0.68 is scoped to fixing the 23 findings from a codebase audit (#1272–#1294), and its plan (#1300) forbids widening scope mid-release — the last two releases each paid for doing that. A new ARM architecture profile is a larger change than anything in that plan, so it will be evaluated when v0.69 is planned rather than squeezed in.

What will happen at that point, so you know what to expect:

• The census gets re-derived on the objects you name rather than taken as given. The 7,346 of 13,187 figure is the starting point, not the plan's number — the v0.67 audit had three of its own counts come out different on re-measurement.
• The question the plan has to answer first is whether ARMv6-M is a new selector profile (lowering to the Thumb-1 subset plus the handful of 32-bit instructions v6-M keeps — BL, MRS/MSR, DMB/DSB/ISB) or an encoder restriction over the existing selector with loud declines for everything that has no v6-M form. Those have very different costs and very different decline surfaces, and it is not honest to guess which before looking.
• Anything synth accepts on the profile will be execution-checked, and anything it cannot lower will decline loudly at compile time. A silently wrong ARMv6-M image — an ARMv7-M instruction on an M0+ is a HardFault, or worse, a different instruction — is the outcome this project exists to prevent.

One thing that would help that evaluation, if it is cheap for you: which of the 22 drivers matter most on the G031, and whether any of them need the MPU on that part. Scoping to the drivers you actually intend to run is much more likely to produce a usable first increment than scoping to all 22.

Refs #1301

[avrabe]

[fathom (gale) — scoping answer for the v0.69 evaluation]

Understood on v0.68. Answers to both questions, with what is measured separated from what is intended:

Which drivers, in order. One driver first, and a first increment that is useful:

1. wdg-thin: the only driver whose silicon oracle already runs on the G031's peripheral map today. Its two-boot IWDG proof passes on F100, WL55, WB55 and G474 via cargo xtask silicon, and the G031's IWDG base (0x4000_3000) plus RCC_CSR RMVF/IWDGRSTF bits are measured on the board. The moment an ARMv6-M wdg-thin object exists, gale can run kill criterion 2 the same day.
2. timer-thin and gpio-thin: next, but they gate on gale's side too. The G031 target model deliberately carries no TIM/GPIO bases yet (nothing measured), so there would be no silicon oracle for them until gale adds those entries.
3. The gust:os node objects (exec-cm3, os-time), after the drivers. Separate concern: they currently depend on a data-address contract gale is fixing (gale#398), and that should settle before they gain a second architecture.

The other 18 drivers have no intended G031 use yet; scoping them in would be guessing.

Does anything need the MPU on that part? No dissolved object does. The G031 does have an MPU (MPU_TYPE 0x0000_0800, 8 regions), and gale's region programmer runs there: the unprivileged-escape probe passes both arms on the G031, with the escape blocked by a HardFault. But that programmer is native Rust (gale::mpu_switch, thumbv6m), not a dissolved object. So the ARMv6-M profile does not need to emit MPU code. One ARMv6-M fact is relevant if that changes later: the minimum region size is 256 B there, versus 32 B on ARMv7-M.

On the census: agreed that it should be re-derived. It was a whole-object mnemonic count with arm-none-eabi-objdump, not a per-reachable-function one. For wdg-thin alone the wide non-BL set is small and regular (movw/movt, .w load/store, stmdb/ldmia, add/sub/and/orr/cmp .w), which may bear on the selector-profile-vs-encoder-restriction question.