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

No way to emit volatile loads/stores #11172

Closed
whitequark opened this issue Dec 28, 2013 · 12 comments · Fixed by #11173
Closed

No way to emit volatile loads/stores #11172

whitequark opened this issue Dec 28, 2013 · 12 comments · Fixed by #11173

Comments

@whitequark
Copy link
Member

I'm interested in using Rust for bare-metal embedded development. For that, Rust would need to support volatile loads and stores.

In a nutshell:

  • Volatile loads and stores represent a barrier preventing compiler from reordering them across other volatile operations (reference).
  • They're mainly used to represent accesses to I/O memory, where normal compiler assumptions don't hold.

C implements them with a pointer attribute. Arguably, semantically it would be a better fit to use an intrinsic function. What should Rust use?

@emberian
Copy link
Member

We need the intrinsics, but could also probably be a smart pointer type (Volatile<T>)

@alexcrichton
Copy link
Member

I like the idea of a smart pointer where T: Pod, but I think that this is a core-enough feature that this warrants a bit of discussion to make sure that this is the right way to go about this. I certainly agree that we need something like this, and I'd be comfortable merging as-is, but I'm curious what others' opinions are.

@emberian
Copy link
Member

Regardless of any sugar we can't do anything without the intrinsics.

@Thiez
Copy link
Contributor

Thiez commented Dec 29, 2013

The atomic instructions rustc emits are also marked volatile in LLVM (unless it has been changed since I added them?). This should probably be changed since atomics need not be volatile.

@bors bors closed this as completed in 1dcc986 Jan 1, 2014
@farcaller
Copy link
Contributor

Any advice how to use this on bare metal, given that bare metal implies #[no_std]?

@whitequark
Copy link
Member Author

@farcaller Directly refer to intrinsics from your code, i.e. like at 1dcc986#diff-09f379e672ff7785f402be1007a06286L175

@huonw
Copy link
Member

huonw commented Mar 22, 2014

extern "rust-intrinsic" {
    pub extern fn volatile_load<T>(src: *T) -> T;
    pub extern fn volatile_store<T>(src: *mut T, value: T);
}

See also the intrinsics module and the brief section on compiler internals in the unsafe guide.

e: oh, @whitequark was faster.

@thestinger
Copy link
Contributor

@farcaller: You can use https://github.com/thestinger/rust-core on bare metal. No need to go through the work of redefining all this stuff yourself.

@nrc
Copy link
Member

nrc commented Apr 27, 2014

So, we have the intrinsics now. Is there any interest in making this more user friendly? Like a smart pointer type or allow annotating variables as volatile?

@huonw
Copy link
Member

huonw commented Apr 28, 2014

@nick29581 there was a pull request adding a wrapper type: #12079.

@thestinger
Copy link
Contributor

I'm not really sure that types make sense. You're only going to need these in rare cases, and the needs are likely quite specific to the use case.

@farcaller
Copy link
Contributor

I've ended up using a modified Cell to do volatile access: https://github.com/hackndev/zinc/blob/master/src/lib/volatile_cell.rs

flip1995 pushed a commit to flip1995/rust that referenced this issue Jul 31, 2023
…sery, r=xFrednet

Move tuple_array_conversions to nursery

changelog: Move [`tuple_array_conversions`] to `nursery` (Now allow-by-default)
<!-- FIY: Ignore this change, if the commit gets backported and also rust-lang/rust-clippy#11146 -->
[rust-lang#11172](rust-lang/rust-clippy#11172)

The nursery change got lost in rust-lang#11146 and it ended up in pedantic, this puts it in nursery and gives something to backport

r? `@xFrednet`
flip1995 pushed a commit to flip1995/rust that referenced this issue Aug 17, 2023
…sery, r=xFrednet

Move tuple_array_conversions to nursery

changelog: Move [`tuple_array_conversions`] to `nursery` (Now allow-by-default)
<!-- FIY: Ignore this change, if the commit gets backported and also rust-lang/rust-clippy#11146 -->
[rust-lang#11172](rust-lang/rust-clippy#11172)

The nursery change got lost in rust-lang#11146 and it ended up in pedantic, this puts it in nursery and gives something to backport

r? `@xFrednet`
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 a pull request may close this issue.

8 participants