Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

make compilable on stable #88

Merged
merged 12 commits into from
May 11, 2018
Merged

make compilable on stable #88

merged 12 commits into from
May 11, 2018

Conversation

japaric
Copy link
Member

@japaric japaric commented Apr 25, 2018

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.

@japaric
Copy link
Member Author

japaric commented Apr 25, 2018

Stuff that has not been converted into external assembly file and thus is not available on
stable:

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.

cc @jcsoo @thejpster @jamesmunns

asm/nop.s Outdated
@@ -0,0 +1,4 @@
.global __nop
__nop:
nop
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We could drop the nop instruction here. Even without it asm::nop won't be optimized away by the compiler.

fn __cpsid();
}

// XXX do we need a explicit compiler barrier here?
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

tweak Exception enum to match CMSIS names, document the parts of the API that require opting into
`"inline-asm"`.
@japaric
Copy link
Member Author

japaric commented May 11, 2018

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>
@bors
Copy link
Contributor

bors bot commented May 11, 2018

Build failed

@japaric
Copy link
Member Author

japaric commented May 11, 2018

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>
@bors
Copy link
Contributor

bors bot commented May 11, 2018

Build failed

@japaric
Copy link
Member Author

japaric commented May 11, 2018

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>
@bors
Copy link
Contributor

bors bot commented May 11, 2018

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
@japaric
Copy link
Member Author

japaric commented May 11, 2018

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>
@bors
Copy link
Contributor

bors bot commented May 11, 2018

Build succeeded

@bors bors bot merged commit 05bbc3b into master May 11, 2018
@japaric japaric deleted the stable branch May 11, 2018 18:07
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
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant