Implement coprocessor access instructions

[spcan]

Implements coprocessor basic access instructions (MCR, MRC, MCRR, MRRC) that compile to a single instruction under --release profiles

[spcan]

CI tests:

• rustfmt fails but functions are formatted the same as the rest of the assembly functions
• stm32 target tests fail due to 3 probes being present: Need to repeat test

[adamgreig]

Thanks for the RP! What's the longer term plan, since these methods are all pub(crate)? Do you imagine adding further coprocessor-related functionality in cortex-m? Should the methods be publicly available?

[spcan]

The aim of these is to expose a common method to interact through the ARM coprocessor interface. Separate libs can then implement the coprocessor driver's using these functions.

For example, I'm using it currently to interact with the LPC55S69 math coprocessor

[adamgreig]

If you want separate libs to later use these functions, don't they need to be pub instead of pub(crate)?

[spcan]

Yeah, good catch, that was there on the test library, forgot to remove it

[spcan]

Ok, it's now failing to compile because const ASM operands are unstable, needing #![feature(asm_const)], can this be enabled in the crate, or should this PR wait until ASM const is stabilized??

This is getting stabilized soon as per #93332

[jannic]

This is getting stabilized soon as per #93332

Likely in rust 1.82.0.

[spcan]

Hello

With the stabilization of Rust 1.82 asm_const has been stabilized. This should be enough to merge these instructions into cortex-m without breaking, although there is the caveat of a new minimum Rust version now (1.82).

Additionally, with the release of the new RP2350 chip, there is now another mainstream processor with coprocessors, which adds some necessity to the access to coprocessor instructions.

I would like some input from somebody in the team of how to proceed at this point, if I should close this PR and open a new one, keep this PR or maybe spin this functionality into a different crate.

Many thanks

[thejpster]

which adds some necessity to the access to coprocessor instructions

The rp2350-hal uses inline assembler to make use of the instructions. Nicer APIs would be better though.

[jonathanpallant]

I don't think we can raise the MSRV up to 1.82 - this crate is very widely used.

[thalesfragoso]

Why all the function docs start with: Internal function (...)? If it's because the functions used to be pub(crate), then the text should be updated.

[jonathanpallant]

I think we should put these behind a feature flag, and note that enabling the feature will raise the MSRV. I also wonder if the functions should be unsafe - can UB be introduced by calling these functions? I suspect so.

[spcan]

Updated all docs on the functions, added information on the meaning of the constants for the functions.

@jonathanpallant This is a low level function for coprocessors, they can introduce UB in the coprocessors, but it's on the libraries / drivers for those coprocessors who should check that. On cortex-m code what can happen is an UsageFault if either the Coprocessor it points to is not enabled (or the arguments are not okay) or a SecureFault if the Coprocessor is enabled only for Secure code and this gets called from Non-Secure code (but it's not UB, this is documented in the TRM for Cortex-M). I'm open to make them unsafe.

@thalesfragoso Updated all documentation.

[jonathanpallant]

We talked about this one in the meeting. We think the API should be unsafe, so the callers know that there are risks if you perform the wrong operation here (just like core::arch::asm! is unsafe).

I'm also going to raise the MSRV on the cortex-m library, but I haven't yet decided if I'm going to raise it as high as 1.82. If we don't, the functions will need to go behind a feature flag.