make compilable on stable #88
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Given that this list is very short and the stuff in there is not commonly used I think it makes rust-embedded/wg#63 much less urgent. |
japaric
commented
Apr 25, 2018
asm/nop.s
Outdated
| @@ -0,0 +1,4 @@ | |||
| .global __nop | |||
| __nop: | |||
| nop | |||
There was a problem hiding this comment.
We could drop the nop instruction here. Even without it asm::nop won't be optimized away by the compiler.
japaric
commented
Apr 25, 2018
| fn __cpsid(); | ||
| } | ||
|
|
||
| // XXX do we need a explicit compiler barrier here? |
There was a problem hiding this comment.
My experiments indicate that FFI calls behave the same as asm!("" ::: "memory" : "volatile") (I suppose because the code that's being called could be doing an assembly call with those clobbers (?)) so I think compiler_barrier is not necessary here.
This was referenced Apr 26, 2018
tweak Exception enum to match CMSIS names, document the parts of the API that require opting into `"inline-asm"`.
|
bors r+ |
bors bot
added a commit
that referenced
this pull request
May 11, 2018
88: make compilable on stable r=japaric a=japaric This PR makes this crate compilable on stable when the "inline-asm" and "singleton" Cargo features are disabled (they are enabled by default to maintain backwards compatibility). The main change has been replacing almost (\*) all inline `asm!` invocations with FFI calls into external assembly files. (\*) Stuff that has not been converted into external assembly file and thus is not available on stable: - Reading the (A)PSR register (I'm not sure if this will work with the extra function call overhead) - Reading and writing the Link Register (LR) - Reading and writing the Program Counter (PC) I would appreciate if someone checked that all the stuff that's now using FFI calls has the same semantics as the inline `asm!` version. Co-authored-by: Jorge Aparicio <jorge@japaric.io>
Build failed |
|
bors r+ |
bors bot
added a commit
that referenced
this pull request
May 11, 2018
88: make compilable on stable r=japaric a=japaric This PR makes this crate compilable on stable when the "inline-asm" and "singleton" Cargo features are disabled (they are enabled by default to maintain backwards compatibility). The main change has been replacing almost (\*) all inline `asm!` invocations with FFI calls into external assembly files. (\*) Stuff that has not been converted into external assembly file and thus is not available on stable: - Reading the (A)PSR register (I'm not sure if this will work with the extra function call overhead) - Reading and writing the Link Register (LR) - Reading and writing the Program Counter (PC) I would appreciate if someone checked that all the stuff that's now using FFI calls has the same semantics as the inline `asm!` version. Co-authored-by: Jorge Aparicio <jorge@japaric.io>
Build failed |
|
bors r+ |
bors bot
added a commit
that referenced
this pull request
May 11, 2018
88: make compilable on stable r=japaric a=japaric This PR makes this crate compilable on stable when the "inline-asm" and "singleton" Cargo features are disabled (they are enabled by default to maintain backwards compatibility). The main change has been replacing almost (\*) all inline `asm!` invocations with FFI calls into external assembly files. (\*) Stuff that has not been converted into external assembly file and thus is not available on stable: - Reading the (A)PSR register (I'm not sure if this will work with the extra function call overhead) - Reading and writing the Link Register (LR) - Reading and writing the Program Counter (PC) I would appreciate if someone checked that all the stuff that's now using FFI calls has the same semantics as the inline `asm!` version. Co-authored-by: Jorge Aparicio <jorge@japaric.io>
Build failed |
when targeting a sub-architecture where the peripheral is actually not available then the field will be unusable: its type won't provide an API to use. This makes svd2rust and cortex-m-rtfm easier to implement
|
bors r+ |
bors bot
added a commit
that referenced
this pull request
May 11, 2018
88: make compilable on stable r=japaric a=japaric This PR makes this crate compilable on stable when the "inline-asm" and "singleton" Cargo features are disabled (they are enabled by default to maintain backwards compatibility). The main change has been replacing almost (\*) all inline `asm!` invocations with FFI calls into external assembly files. (\*) Stuff that has not been converted into external assembly file and thus is not available on stable: - Reading the (A)PSR register (I'm not sure if this will work with the extra function call overhead) - Reading and writing the Link Register (LR) - Reading and writing the Program Counter (PC) I would appreciate if someone checked that all the stuff that's now using FFI calls has the same semantics as the inline `asm!` version. Co-authored-by: Jorge Aparicio <jorge@japaric.io>
Build succeeded |
bors bot
added a commit
to rust-embedded/panic-itm
that referenced
this pull request
May 11, 2018
1: use less unstable features r=japaric a=japaric depends on rust-embedded/cortex-m#88 Co-authored-by: Jorge Aparicio <jorge@japaric.io>
bors bot
added a commit
to rust-embedded/cortex-m-quickstart
that referenced
this pull request
May 12, 2018
29: use less unstable dependencies r=japaric a=japaric This PR and the ones at the bottom reduce the number of unstable features needed for Cortex-M development to a single one: `lang = "panic_fmt"`, which already has a path towards stabilization and which we hope to get on stable by 1.28. [Check out the temporary documentation](https://japaric.github.io/cortex-m-quickstart/cortex_m_quickstart/index.html) (we still need more docs) to try out this preview. We would love your input on [these unresolved questions](rust-embedded/cortex-m-rt#69 (comment)) This PR depends on: - rust-embedded/cortex-m-rt#69 - rust-embedded/cortex-m#88 - rust-embedded/panic-semihosting#2 - rust-embedded/svd2rust#203 - japaric/stm32f103xx#24 Co-authored-by: Jorge Aparicio <jorge@japaric.io>
adamgreig
added a commit
that referenced
this pull request
Jan 12, 2022
88: v0.5.2 r=therealprof a=japaric changes required for a new release this commit also simplifies the examples by removing the exception handler overrides and adds an example that overrides the exception handlers. r? @adamgreig (chosen at random) Co-authored-by: Jorge Aparicio <jorge@japaric.io> Co-authored-by: Adam Greig <adam@adamgreig.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR makes this crate compilable on stable when the "inline-asm" and "singleton" Cargo features
are disabled (they are enabled by default to maintain backwards compatibility).
The main change has been replacing almost (*) all inline
asm!invocations with FFI calls intoexternal assembly files.
(*) Stuff that has not been converted into external assembly file and thus is not available on
stable:
Reading the (A)PSR register (I'm not sure if this will work with the extra function call overhead)
Reading and writing the Link Register (LR)
Reading and writing the Program Counter (PC)
I would appreciate if someone checked that all the stuff that's now using FFI calls has the same
semantics as the inline
asm!version.