[riot-notifications] [RIOT-OS/RIOT] cpu/atmega_common: RTT and RTC support (#8842)
notifications at github.com
Sat Apr 20 18:59:24 CEST 2019
> @ZetaR60: I happily admit that my knowledge about the technical details of `volatile` are limited. But I am aware of the consensus among C developers regarding the usage of `volatile` and we should stick to that, unless we have a very, very good reason to not do so.
You are making two _faulty generalizations_ here. The first is that because _most_ developers aren't aware of the nuances of the use of volatile that _I_ am not aware of the nuances of its use. If your question was "should a developer who is not aware of the nuances of volatile use it", I would answer _no_, which is the consensus among C developers. The other faulty generalization is that since _in typical environments_ there are better tools than volatile, that _in all environments_ there are better tools than volatile. Your Corbet and Robinson citations apply specifically to those typical environments, and your Regehr citation _explicitly agrees_ with my assessment:
> If you are writing code for an in-order embedded processor and have little or no infrastructure besides the C compiler, you may need to lean more heavily on volatile.
Furthermore, you cannot adjudicate the nuances of a consensus regarding a particular construction if _you do not understand that construction_. The most that should be done in this circumstance is determine whether the developer in question _has a detailed and nuanced understanding_ of the construction, and has significant reasons for the construction's use based on that nuanced understanding. If that determination has been made, as it has been _adequately demonstrated_ in this circumstance, strict imperatives involving its use _should stop there_. That imperative process should only continue if the one adjudicating has _specific and nuanced_ reasons based in a good understanding that preferably could be backed up by _primary sources_ if disagreement continues. You have freely admitted that you currently lack that nuanced understanding, and I do not fault you for that. I, however, feel that falling back on tertiary sources, i.e. _opinion pieces_, without a nuanced understanding of the underlying reasons for those opinions is not proper in this circumstance. Also, I am dismayed by the zealousness with which you are persuing this issue.
> The degree by which ordering is guaranteed when using `volatile` accesses depends on who you ask. This is a very bad feature if compilers give different guarantees on that
It _does not depend_. It is _explicity guaranteed_ by the specification, which I have demonstrated. Those who are claiming that that it does not need to read the specification! If a compiler does not give the same guarantee as the specification then _that compiler is broken_.
> It is totally useless on systems that have out of order execution or multiple processor (cores). This is not yet relevant for RIOT, but it seems to be a matter of time until out of order processors hit the embedded market. Also RIOT is already running on the ESP32 (using only one core), so RIOT might gain support for running on more than one processor (core) soon.
I do not have experience on out of order execution and cannot provide rigorous comments on it, except that it is not germaine to the current circumstance. The sentiment that volatile is "totally useless" on multi-processor is _generally true_. However, like many principles in programming, it is _improper_ to universalize prohibitions, and to try and adjudicate others that have a specific exception informed by a nuanced understanding when you do not have a nuanced understanding yourself. Also, opinions on the general state of programming will be _inapplicable_ to MCU systems without knowledge on the specific construction in the context of those differences.
> The Linux kernel guys are explicitly forbidding the use of `volatile` variables except for memory directly linked to hardware (and some “stupid legacy” code) https://www.kernel.org/doc/html/latest/process/volatile-considered-harmful.html Unlike me (as you pointed out) , those guys have the required expertise to draw the conclusion that `volatile` is considered harmful.
> > Memory barriers should not be used as a replacement for volatile. Volatile prevents only reordering with other volatile accesses, but memory barriers prevent all forms of optimization from passing the memory barrier.
> This is not true. `volatile` prevents the reordering by the compiler, which is does work on in-order single-core single-threaded CPUs. Memory barrier work on every system.
Their claims apply specifically to systems that have more services available to accomplish tasks that require volatile. This does _not apply_ in this circumstance because the necessary servies _are not available_ in ISR mode, and making ISRs more complex is _highly undesirable_ in RIOT. Also, memory barriers are not the correct construct to apply here, because preventing reordering with other volatile accesses and enforcing repeated reads/writes is _exactly_ what is needed here, and preventing all forms of optimization from passing the memory barrier is _undesirable_.
> Summing up: You are using `volatile` for something it is historically not intended to be used. The consensus among C programmer is to not do what you are doing. Please provide reasonable and strong technical justification for that, or stop using `volatile` there.
My use of volatile is _specifically and explicitly_ given as an example in _the C99 standard document_ as a _correct and necessary_ use of volatile! You have not provided any evidence that what I am doing is not according to consensus of C programmers with a nuanced understanding of volatile because your _tertiary_ sources apply to circumstances that are _not applicable here_, and one of your sources _explicitly states that volatile may be required in this circumstance_. Also, I have _provided resonable and strong technical justification_ in prior posts, and you have apparently _ignored it_!
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the notifications