Follow-up Comment #6, bug #14616 (project avr-libc):
Joerg Wunsch wrote on Montag, 26. September 2005 21:04 :
GCC's documentation says:
The `volatile' keyword indicates that the instruction has important
side-effects. GCC will not delete a volatile `asm' if it is reachable.
(The
Follow-up Comment #5, bug #14616 (project avr-libc):
The unfortunate thing is, that using volatile is not enough. Even if it works
for your extremely simple test case: I am having a more complex test case
example in my application code, where it does *not* work because gcc reorders
the
As anonymous wrote:
FYI: I had started with code like
{
uint8_t temp = SREG;
asm volatile (cli : :);
volatile_declared_uint16_t_var_in_memory = value;
SREG = temp;
}
Here gcc had reordered it such that it would read
{
uint8_t temp = SREG;
asm volatile (cli : :);
As Russell Shaw wrote:
Linux code has rmb() and wmb() for read memory barrier and write
memory barrier, to solve that reordering problem. Something might
be learned from finding how those macros are defined.
They end up in a spaghetti of header files, but if my brain can
trace that right,
Dmitry K. wrote on Dienstag, 27. September 2005 05:03 :
On Tuesday 27 September 2005 01:54, Björn wrote:
Follow-up Comment #5, bug #14616 (project avr-libc):
The unfortunate thing is, that using volatile is not enough. Even if it
works for your extremely simple test case: I am having a
Follow-up Comment #3, bug #14616 (project avr-libc):
Dimitry wrote:
May be, if necessary it is better to add 'volatile' in
definition of a concrete variable, than to endow speed always?
The problem is that declaring the variable to be volatile does not prevent
the problem. The issue is that
