avr-libc-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [avr-libc-dev] [bug #14616] definition of sei() in interrupts.h is f


From: Joerg Wunsch
Subject: Re: [avr-libc-dev] [bug #14616] definition of sei() in interrupts.h is faulty
Date: Mon, 26 Sep 2005 21:04:15 +0200
User-agent: Mutt/1.4.2.1i

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" : :);
>   SREG = temp;
>   volatile_declared_uint16_t_var_in_memory = value;
> }

This looks like a bug to me.  After all, the entire purpose of
declaring the asm statement `volatile' was to tell the compiler that
it must *not* move it elsewhere.  As SREG itself is also a volatile
object, this looks like a genuine bug to me.

Can you try discussing that with the GCC folks?

Also, the inline asm cookbook suggests that declaring the critical
variable volatile instead of forcing the compiler to treat *any*
variable as volatile would be the preferrable way.  After all, when
Harald Kipp wrote that, he must have taken that logic from somewhere,
so it rather appears to me that GCC has moved away from something that
used to be at leasted established practice -- and a useful one, it
seems.

Sure, we can hack up sei() to force all variables becoming volatile by
the clobber attribute "memory", but I'd rather prefer if GCC would
accept the current behaviour as buggy, and fix it, as the former would
also lose optimization on those variables the application programmer
wasn't even interested at all.

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 instruction can still be deleted if GCC can prove that
control-flow will never reach the location of the instruction.)  In
addition, GCC will not reschedule instructions across a volatile `asm'
instruction.

(Btw., I cannot find any documentation for the "memory" constraint.)

-- 
cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/                        NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)





reply via email to

[Prev in Thread] Current Thread [Next in Thread]