[riot-notifications] [RIOT-OS/RIOT] sys: Added simple memory barrier API (#11438)

Kaspar Schleiser notifications at github.com
Wed Apr 24 17:24:05 CEST 2019


kaspar030 commented on this pull request.



> + * located at address `0x42` and we want to use that to measure the time a call
+ * to `void do_computing(void)` takes:
+ *
+ * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ {.c}
+ * // BEWARE: This example deliberately contains **BUGS**
+ * #define TIMER    (*((uint16_t *)0x42))
+ *
+ * uint16_t measure_time(void) {
+ *     uint16_t pre = TIMER;
+ *     do_computing();
+ *     uint16_t post = TIMER;
+ *     return pre - post;
+ * }
+ * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ *
+ * In the above example from the compilers perspective the value in `TIMER`

Have you seen this behaviour in practice?

> + * uint16_t measure_time(void) {
+ *     uint16_t pre = TIMER;
+ *     do_computing();
+ *     uint16_t post = TIMER;
+ *     return pre - post;
+ * }
+ * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ *
+ * In the above example the compiler will now dutifully generate code to access
+ * the timer register two times. The compiler will also not reorder any
+ * `volatile` memory access in regard to any other `volatile` memory access.
+ * But some compilers will reorder non-`volatile` accesses across `volatile`
+ * memory accesses. If the implementation of `do_computing()` is visible to the
+ * compiler, the compiler may conclude that do_computing() could be moved
+ * above the first or below the second access to `TIMER`, which will render the
+ * benchmark meaningless. (**Beware:** Even if `do_something()` is an external

> I made the experiment a while ago with a some functions defined in a single C file (no LTO), mixing accesses to globals and calls. GCC is smart enough to realize that some function do not touch global memory. I'm not sure if LTO is also as smart.

This sounds like anecdotal evidence.

-- 
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/11438#pullrequestreview-230183528
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.riot-os.org/pipermail/notifications/attachments/20190424/4ea66e43/attachment.html>


More information about the notifications mailing list