[riot-notifications] [RIOT-OS/RIOT] cpu/atmega_common: RTT and RTC support (#8842)

ZetaR60 notifications at github.com
Thu Apr 18 23:14:04 CEST 2019


> > An object that has volatile-qualified type may be modified in ways unknown to the implementation or have other unknown side effects.
> 
> In other words: Hardware that is somehow mapped into the memory has to be volatile. The state structures you're declaring resides in ordinary memory: It is not changed by the hardware, nor does changing it have any side effects like changing the voltage level at a GPIO pin. This is not a use case for `volatile`.

You are drawing conclusions that do not follow from the narrow claim. Running an ISR is not a part of the original process state machine and is therefore "unknown" to it. This is exactly what volatile is intended for, and exactly what I am using it for.

> > Furthermore, at every sequence point the value last stored in the object shall agree with that prescribed by the abstract machine, except as modified by the unknown factors mentioned previously.
> 
> ```c
>     TIMSK2 &= ~(1 << OCIE2A); /* <-- volatile access */
> 
>     [some rtt_state accesses] /* <-- sequence points */
> 
>     TIMSK2 |= (1 << OCIE2A); /* <-- volatile access */
> ```
> 
> This means specifically, that during the access to the `rtt_state`, which are sequence points, "the value last stored in the object [here `TIMSK2`] shall agree with that prescribed by the abstract machine". This means during those accesses, the volatile object `TIMSK2` must have the value "interrupts disabled".

This is a section specifically on the nature of volatile objects. I have added some implied language to the quote in question:

> Furthermore, at every sequence point the value _of the volatile object_ last stored in the _volatile_ object shall agree with that prescribed by the abstract machine, except as modified by the unknown factors mentioned previously.

This does not guarantee the state of `rtt_state` during an expression with `TIMSK2`, unless that expression also refers to `rtt_state`.

> But, as seeing is believing:
> [snipped example code]
> 
> Here the accesses to `a` get still optimized and reordered, as they all have been between the two accesses two `interrupts_enabled`. Those accesses to `b` that are supposed to happen while interrupts are disabled are indeed happening then, and those supposed to happen when interrupts are enabled again are happening there.

Okay, so in that case GCC is evaluating the code in the manner you describe, but this is not guaranteed by the specification. The specification makes it clear that this is implementation defined and cannot be relied on.

§5.1.2.3 (which is referred to by the previous section I mentioned):
¶8
> EXAMPLE 1    An implementation might define a one-to-one correspondence between abstract and actual semantics: at every sequence point, the values of the actual objects would agree with those specified by the abstract semantics.  The keyword volatile would then be redundant.

¶9
> Alternatively,  an  implementation  might  perform  various  optimizations  within  each  translation  unit,  such that the actual semantics would agree with the abstract semantics only when making function calls across translation  unit  boundaries.   In  such  an  implementation,  at  the  time  of  each  function  entry  and  function return where the calling function and the called function are in different translation units, the values of all externally  linked  objects  and  of  all  objects  accessible  via  pointers  therein  would  agree  with  the  abstract semantics.  Furthermore, at the time of each such function entry the values of the parameters of the called function and of all objects accessible via pointers therein would agree with the abstract semantics.  In this type of implementation, _objects referred to by interrupt service routines_ activated by the signal function would  _require  explicit  specification  of volatile storage_,  as  well  as  other  implementation-defined restrictions.

Italics mine on paragraph 9.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/RIOT-OS/RIOT/pull/8842#issuecomment-484691950
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.riot-os.org/pipermail/notifications/attachments/20190418/65f98d13/attachment-0001.html>


More information about the notifications mailing list