Revise arm platform notes regarding soft float

[thejpster]

This PR updates the Arm microcontroller platform docs to recommend -fpregs instead of +soft-float as discussed on Zulip

[rustbot]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @ehuss (or someone else) some time within the next two weeks.

Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (S-waiting-on-review and S-waiting-on-author) stays updated, invoking these commands when appropriate:

• @rustbot author: the review is finished, PR author should check the comments and take action accordingly
• @rustbot review: the author is ready for a review, this PR will be queued again in the reviewer's queue

[rustbot]

Some changes occurred in src/doc/rustc/src/platform-support

cc @Noratrieb

[ehuss]

@rustbot ping arm

Can an Arm maintainer review this, please?

Or, cc @RalfJung, since I've noticed the two of you discussing this on Zulip, if you want to review this.

[rustbot]

Hey ARM Group! This bug has been identified as a good "ARM candidate".
In case it's useful, here are some instructions for tackling these sorts of
bugs. Maybe take a look?
Thanks! <3

cc @adamgemmell @davidtwco @hug-dev @jacobbramley @JamieCunliffe @joaopaulocarreiro @raw-bin @Stammark

[thejpster]

AIUI there are no Arm maintainers for M-Profile, only for the Aarch64 A-Profile. Although they offered to help on a best-effort basis.

The designated maintainer is the Cortex-M Team in the Embedded Devices Working Group. I don't think you can ping them on github but I'll post this on their matrix room.

[jamesmunns]

CC @adamgreig @thalesfragoso @newAM

[jacobbramley]

This seems to do the right thing (at least for the cases I tried and based on the Zulip discussion), and no alarm bells went off when I discussed it with our LLVM teams.

One caveat we noticed — which is really a separate concern — is that there's no way to specify eabihf with no FP. That sounds nonsensical, but it's potentially useful with integer MVE, which uses the same registers. Clang achieves that with +nofp, which seems to get translated into -mfpu=none, but I can't find a way to control that through Rust.

[thejpster]

Does Integer MVE let you use s0 and d0 even without an FPU?! Wild.

[jacobbramley]

Does Integer MVE let you use s0 and d0 even without an FPU?! Wild.

Yes, at least for the few instructions you'd need to use this ABI. I've not done any real work on these devices so can't claim to be an expert, but the Armv8-M reference manual says that the necessary VMOV instructions are available with either FP or MVE.

The FP/vector register file is overlaid so that q0 aliases d1:d0 and s3:s2:s1:s0, just like A-class AArch32's Neon registers. You could read d0 as "the lower 64 bits of q0", which might feel more natural in a world without FP hardware. There's a layout diagram under rule R_BBYH, page 180 in version B.y of the manual.

[thejpster]

Does Integer MVE let you use s0 and d0 even without an FPU?! Wild.

Yes, at least for the few instructions you'd need to use this ABI. I've not done any real work on these devices so can't claim to be an expert, but the Armv8-M reference manual says that the necessary VMOV instructions are available with either FP or MVE.

The FP/vector register file is overlaid so that q0 aliases d1:d0 and s3:s2:s1:s0, just like A-class AArch32's Neon registers. You could read d0 as "the lower 64 bits of q0", which might feel more natural in a world without FP hardware. There's a layout diagram under rule RBBYH, page 180 in version B.y of the manual.

OK, I added some notes to mention that this is a potentially valid setup.