-
Notifications
You must be signed in to change notification settings - Fork 3
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
Use core atomic types instead of intrinsics on non-MSP430 targets #6
Conversation
Btw, an alternative idea is using core atomic types instead of intrinsics on non-MSP430 targets: taiki-e@a5512a9 |
I don't remember the rationale for making the API function names reflect the intrinsics rather than "the API provided by cc: @pftbest Do you object if the API is updated (in a breaking change) to reflect |
Hello @cr1901, The idea of this crate was to keep public API exactly the same as in std to simply porting code written for another platforms. The internal implementation (ie intrinsics, inline asm, atomic types, etc) doesn't really matter as long as public API behaves as expected. I am ok with any internal changes to that effect. |
I'm a little bit confused. Right now, the names in the public API of this crate reflect Additionally, msp430 RMW insns are not sufficient for implementing the return value part of the functions provided by |
@cr1901 Sorry, I guess I did forget this part. You are right it's not possible to have a matching API. I'm not sure why I went with the intrinsics API at the time. Following intrinsics API doesn't really make sense because it's unstable by definition and it's not used in practice. Updating API to match |
@pftbest I will hold onto this as an alternate alternate idea. I think I want to deprecate this crate
@taiki-e Do you mind if we use your alternate idea for this PR? I think short-to-medium term plans are to deprecate this crate and either use your portable-atomic crate (looks fine, although the scary |
31: Always provide atomic CAS for MSP430 and AVR r=taiki-e a=taiki-e This previously required unsafe cfg `portable_atomic_unsafe_assume_single_core`, but since all MSP430 and AVR are single-core, we can safely provide atomic CAS based on disabling interrupts. Thanks `@cr1901` for pointing out this in pftbest/msp430-atomic#6 (comment). Co-authored-by: Taiki Endo <te316e89@gmail.com>
Updated to use it.
Sounds good to me. For |
Since rust-lang/rust#97423, build on non-MSP430 targets is failing.
log