Pre-RFC: Stabilize volatile copy and set functions

Greetings. I have written a “pre-RFC” (flagrantly plagiarized from RFC 1467) proposing stabilizing volatile copy and set intrinsics behind stable interfaces. This addresses some specific use cases for a project I’m working on at work. Taylor Cramer has looked it over and thinks the wording is ok; I’m posting here to cast a wider net for feedback. Thank you!

3 Likes

I left some inline comments on the branch.

I attempted to address them; I think I also may have, uh, inadvertently blown away the comments. :-/ I need to brush up my hub fu.

Seems they are still there.

For RFC reviews, I personally recommend making a branch against the master of your fork and then having review comments on that one. It works pretty well.

This looks really helpful!

This should handle any cases of general memory copies.

However, I’ve also run into cases that require operating on a 2-byte or 4-byte or 8-byte quantity as a unit, not as a series of bytes. The equivalent in C would be writing through a volatile uint32_t *, for instance. This comes up especially when doing device I/O, as well as when carefully constructing new synchronization primitives.

Could you document how code that needs to write a u16 or u32 or usize or (on some platforms only) a u64 as a unit should handle that (which may require some additional primitives)? The result needs to compile to a single machine instruction to move the value to memory, not a series of byte moves.

1 Like

Sorry, I kinda had some unexpected dental work that took a week to resolve and then this slide to the side. My bad!

My sense regarding larger width types is that those are better handled in terms of the existing interfaces: I believe that ptr::read_volatile and ptr::write_volatile might provide the relevant semantics for multi-byte quantities. If one wished to write several multibyte data, then it may be appropriate to do so in an explicit loop.

However, reading the documentation for the existing volatile interfaces perhaps my belief is aspirational rather than informed by reality vis existing practice. The documentation says nothing about semantics of multi-byte writes, though it does allude to C11. It’s not clear to me that C11 has anything to say about the atomicity of multibyte writes, however.

Part of me feels this may be best addressed in a wider-scoped effort, though. I don’t want to make this particular change too broad.