Tracking issue for stable inline assembly #420
Comments
bors bot
added a commit
that referenced
this issue
Mar 1, 2022
423: Swap to just-stabilised asm!() and global_asm!() macros r=thejpster a=adamgreig Once Rust 1.59 is released in a couple of days, the `asm!()` and `global_asm!()` macros will become stable, and we will no longer require the various precompiled binaries we've used until now in cortex-m and cortex-m-rt. cc #420. This PR uses `asm!()` in cortex-m, and removes the inline-asm feature, since I anticipate this going into cortex-m 0.8 and so we don't need to leave it behind for compatibility. In various places the previous version would call an extern C method when built for the native target, which would only fail at link time; to preserve the ability to build on x86 I've either made the whole method require the `cortex_m` configuration, or where appropriate/convenient simply skipped the `asm!()` call. This PR replaces the old gcc-preprocessed `asm.S` in cortex-m-rt with use of `global_asm!()`, although since you can't normally use `#[cfg(...)]` attributes with `global_asm!()`, there's also a slightly scary macro modified from one invented by `@Dirbaio` for a similar purpose. I considered putting the initialisation of LR behind an armv6m flag, but since we want to restore it after calling `__pre_init` it seemed better to just leave it the same on both targets. I added Cargo features to optionally set SP and VTOR at startup, which has been variously requested but would previously have required multiplicatively more pre-built binaries. Now: no problem. Relevant issues: * rust-embedded/cortex-m-rt#283 * rust-embedded/cortex-m-rt#55 * rust-embedded/cortex-m-rt#254 * rust-embedded/cortex-m-rt#102 * rust-embedded/cortex-m-rt#338 I've tested these on a couple of targets (and updated the CI): on the whole there's a small improvement in code size due to everyone getting inlined asm, especially in `cortex_m::interrupt::free()`. The major downside is we bump our MSRV from 1.42 (March 2020) to 1.59 (Feb 2022). For cortex-m, I propose putting these changes in the upcoming 0.8 release (which is technically what the master branch is already on) and not backporting. For cortex-m-rt I'm not sure: we don't have any other pending breaking changes, so we could consider a patch release. Anyway, this PR doesn't commit to any particular releases, so we can decide that later. For cortex-m-semihosting/panic-semihosting I think a patch release would be ideal, especially since we had to yank the last c-m-sh release due to conflicting prebuilt binaries (a problem that should now vanish). Also tagging these issues that I think might also benefit from new inline asm: * #265 * #215 * #406 Co-authored-by: Adam Greig <[email protected]>
|
I just stumbled across this issue while doing some research. Can this be closed? I can't find any assembly in this repository that's not within |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The next stable Rust release, 1.59, will include stable
asm!()andglobal_asm!()macros that finally permit us to define assembly directly in the crate without needing to distribute precompiled binaries.I anticipate this will let us remove all the current code to support precompiled binaries, including the outlined-inlined-asm in cortex-m and the
asm.Sin cortex-m-rt, and make all ourinline-asmfeatures no-ops. Since this shouldn't be a breaking change to users, it could be released as a cortex-m 0.7 backport, or as part of the upcoming 0.8, and as a normal minor 0.7 release for cortex-m-rt.This issue is for tracking progress/concerns/problems.
The text was updated successfully, but these errors were encountered: