4 ms·
If you remove the volatile keyword on variables/attributes how do you ensure that a variable that needs to be accessed with volatile read/write always uses such
by audunw 3y ago
If you remove the volatile keyword on variables/attributes how do you ensure that a variable that needs to be accessed with volatile read/write always uses such intrinsics?
Seems to me that you want to keep the keyword but give a warning or suppressible error if it’s not accessed through volatileRead/Write intrinsics. (Hobby/hacking level development of embedded software if every other line was a volatileRead/Write call, but good to enforce in professional software development)
- tialaramex 3y agoSeveral techniques are possible as a standard library type, you needn't provide a mechanism to alter such a variable at all except via these intrinsics. I am not sufficiently experienced in Zig to offer a strong opinion about how I'd prefer it to be done there, but in general a wrapper type which prevents the programmer from just improperly using the MMIO address (via any other method) needn't add any overhead to the compiled software compared to the raw pointer used today with the keyword. We're not trying here to prevent malevolent actors from causing trouble or trying to entirely prevent foot shooting here, only to require that weapons capable of targeting your own feet are kept separate from the ammunition in a locked cabinet, so that the newbie will ask, "Hey, I need to get in the locked cabinet so I can write a composite assignment on an MMIO register" and that's your chance to explain why this doesn't do what they expected and what they should write instead.