cbiffle
commented
2 years ago @jperkin thanks for doing this! It's neat.
My initial unsolicited thoughts:
The port looks very plausible. I would like to split the syscall stubs out of userlib/src/lib.rs now that there are two architectures -- perhaps into src/armv6m.rs and src/armv6m.rs and pull them in based on build settings. (This and the RISC-V port also cause me to want to generate the syscall stubs automatically, because there's a lot of duplication going on -- but that's probably a separate issue.)
The branch currently doesn't build. The commit it references in the stm32-nightlies repo has disappeared. The stm32 folks (for reasons I can't explain) don't guarantee that commits on master that repo today will still exist tomorrow -- this is part of why we had to fork it. However, the stm32g070 demo at least does build with the published 0.14 version of stm32g0, so I was able to inspect the results.
I expected that armv6m code would be larger, in general, than armv7m code because of the very limited instruction set, particularly addressing modes. I started by looking at the largest single hunk of code, which is the kernel. Comparison is proving involved, though, because of configuration differences -- since the stm32g0 parts don't implement ITM, and you're leaving them in their default HSI16 clock configuration, the code that actually gets compiled into the kernel is rather different for reasons that have nothing to do with the instruction set. (Also, so that I don't have to do this math again: the stm32h7's vector table is 476 bytes larger than the stm32g0's.)
A more apples-to-apples comparison is the user-leds task.
text data bss dec hex filename
6068 0 0 6068 17b4 target/demo-stm32g070-nucleo/dist/user_leds
5664 0 0 5664 1620 target/demo-stm32h743-nucleo/dist/user_ledsThat's a 7% difference, and the g070-nucleo's user-leds implementation is simpler than the h743-nucleo's because their LED counts differ. Based on past experience and making numbers up, I'd expect a ~10% increase in code size, which means our nearly-32-kiB kernel is going to start becoming a problem on the smaller m0s.
The syscall calling convention was initially designed for RV32I, then stuffed awkwardly into ARMv7-M; its use of high-numbered registers makes it rather awkward on ARMv6-M, where these registers are second-class citizens. We might be able to improve the syscall stub performance a bit, but your implementations look like a totally reasonable starting point.
By shrinking some of the flash allocations in the app.toml I've got the g070 demo image juuuust under 128kiB of Flash. It's currently using 32kiB of RAM, most of which is going to Hiffy, and I suspect that could be shrunk but since I don't have hardware to test on, I couldn't validate the result. (Not entirely sure what Hiffy is doing with all that RAM.) I notice that tasks are right around 6kiB on average, which suggests that there's several kibibytes of runtime code getting pulled in to everything -- when this happened on ARMv7M it turned out that I'd accidentally done something silly in the panic handler that caused a lot of unused formatting code to appear used to the linker. At some point I'm interested in taking a pass over the armv6m binaries and looking for similar opportunities, but that doesn't need to block merging.
It would be nice to have Cortex-M0+ support for situations in the future where we need a low-cost micro.
@jperkin has a prototype port.
We should talk. :-)