What problem is volatile trying to solve? Would memory types/zones work instead?

[kyle-github]

This is to take the more speculative parts of #4284 out somewhere else for discussion.

From the examples given, the driver behind having volatile at all is from embedded programming. However, I see some problems here:

• Embedded programs often need more memory types or areas or zones than other programs since embedded processors have things like fast vs. slow RAM, EEPROM, FLASH etc. A single volatile concept does not cover that. Embedded systems do not have just one kind of memory.
• volatile is considered to be a hack in C and C++ by many and there are active proposals to remove it. While these are unlikely to get traction due to backwards compatibility requirements, there is a lot of discussion about this in those communities. Does Zig want to embrace the C volatile model or do something different?

If the driving case for volatile is embedded systems, then it seems like it is not solving the real problem which is the lack of support for different kinds of memory.

I don't have any concrete proposals here, but if I was to push forward with this, it would probably have a single new concept:

Memory Types

Create a concept of memory types or spaces in Zig. These need to allow for things like:

• varying speed (fast vs. slow RAM),
• varying address size (zero page RAM vs. other RAM),
• page vs. byte writes (things like FLASH),
• write once vs. multiple writes (various FLASH etc.)
• read only vs. write only vs read-write,
• allowing the compiler to decide where a variables lives vs. providing a fixed address (MMIO),
• cacheable vs. not cacheable (this is where part of the coverage of volatile comes in as well),
• ... and other aspects ...

The various features of Zig like comptime would make it an excellent platform for embedded programming if the memory type problem can be solved within the language. C compilers usually have platform-specific hacks that bend the language in various ways. There are not an infinite number of these variations or types of memory. Five or six would cover a large part of the embedded space.

As a quick example, for a MMIO register, you could declare the variable with a fixed address and mark it as non-cacheable. If it is not cacheable, then the compiler certainly should not be storing the value in a register.

[andrewrk]

https://ziglang.org/documentation/master/#volatile

Would memory types/zones work instead?

No. volatile is here to stay, the only open question is whether it applies to loads and stores (with #4284) or pointer attribute (status quo).

I'm confident about this and so closing the issue.

If you want to learn more about volatile or discuss, I recommend to start a discussion in one of the community areas.

[kyle-github]

Fair enough.