emit non-atomic instructions when --single-threaded

[andrewrk]

Now that #1764 is implemented, we need to improve language support for it. When building with --single-threaded:

• @atomicLoad should be a normal (non-atomic) load
• @atomicRmw should be a normal (non-atomic) read, modify, write
• @fence should be a no-op

[daurnimator]

Just because the current program is single threaded doesn't mean the whole machine is. e.g. you could br using memory mapped or DMAd buffers.
In reply to your IRC comment, I don't think volatile is enough: IIRC volatile in C only ensures that the number of reads/writes in code map exactly to the number of reads/write to memory: it doesn't have any ordering guarantees.

[andrewrk]

volatile guarantees order and it is appropriate for DMA. From the zig docs:

Loads and stores are assumed to not have side effects. If a given load or store should have side effects, such as Memory Mapped Input/Output (MMIO), use volatile. In the following code, loads and stores with mmio_ptr are guaranteed to all happen and in the same order as in source code:

It is incorrect to use atomics for DMA or memory mapped I/O.

[andrewrk]

I do want to collect more information before committing to this. I recall needing to use @fence even for a single threaded OS kernel:

https://github.com/andrewrk/clashos/blob/e55b6a26a5c01566da14b5f1306822c8da6fc978/src/mmio.zig#L3-L11

[daurnimator]

This also came up in bindings to the linux kernel's uring (#2525).
The kernel has a memory fence on its side, and you have to have a matching one in userspace.

Additionally, .Monotonic atomic operations are merely to ensure ordering of operations so that the compiler doesn't reorder them, this matters for memory mapped IO and lots of low level operations.

Which means:

• single threaded running under an OS (e.g. linux), still needs to honour atomic operations
• single threaded that deals with raw device still need to honour atomic operations

I think that's probably every program in the world.... in other words, this issue can be closed.

[andrewrk]

One thing to consider is to using the "singlethread" attribute on the atomic operations:

If an atomic operation is marked syncscope("singlethread"), it only synchronizes with and only participates in the seq_cst total orderings of other operations running in the same thread (for example, in signal handlers).

If an atomic operation is marked syncscope("<target-scope>"), where <target-scope> is a target specific synchronization scope, then it is target dependent if it synchronizes with and participates in the seq_cst total orderings of other operations.

Otherwise, an atomic operation that is not marked syncscope("singlethread") or syncscope("<target-scope>") synchronizes with and participates in the seq_cst total orderings of other operations that are not marked syncscope("singlethread") or syncscope("<target-scope>").