David Brown wrote:
... you are ... protecting the code sequence, not the data itself - the
data is indirectly protected by always using
protected code sequences to access it.
I think this is just a point-of-view thing. I could be wrong, but I think
the prevalent point of view is that it is
Graham Davies wrote:
David Brown wrote:
... you are ... protecting the code sequence, not the data itself -
the data is indirectly protected by always using
protected code sequences to access it.
I think this is just a point-of-view thing. I could be wrong, but I
think the prevalent point
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Andy H
Sent: Thursday, May 22, 2008 5:36 PM
To: David Brown
Cc: avr-gcc-list@nongnu.org
Subject: Re: [avr-gcc-list] Avr-gcc Produces Incorrect Code with -Os
http://gcc.gnu.org/onlinedocs/gcc-4.1.0/gcc/Atomic
Andy H wrote:
BTW
I believe the common attribute/keyword for this should be monitor as in
monitor void dostuff(void)
{
putchar ( ’Z’ );
}
This will give a degree of compatibility with other compilers.
If other compilers use monitor, then that makes sense. It is also
arguably more
Paulo Marques wrote:
Weddington, Eric wrote:
[...]
If ATOMIC_BLOCK() is *the* way to do it, perhaps the docs
could be improved a little by emphasizing the use of
ATOMIC_BLOCK() as a necessity rather than as a convenience.
I'll go a step further: Is there any reason to NOT include the memory
Hi.
An alternative way to handle this sort of thing would be to implement a
critical function attribute like in the msp430 port of gcc - a
function with this attribute has interrupts disabled at the start, and
restored at the end.
It will work for for tiny and mega devices, but xmega
@nongnu.org
Sent: Thu, 22 May 2008 1:08 pm
Subject: Re: [avr-gcc-list] Avr-gcc Produces Incorrect Code with -Os
Hi.
An alternative way to handle this sort of thing would be to implement
a
critical function attribute like in the msp430 port of gcc - a
function with this attribute has interrupts
-Original Message-
From: Anatoly Sokolov [mailto:[EMAIL PROTECTED]
Sent: Thursday, May 22, 2008 11:09 AM
To: Weddington, Eric; David Brown; avr-gcc-list@nongnu.org
Subject: Re: [avr-gcc-list] Avr-gcc Produces Incorrect Code with -Os
Hi.
An alternative way to handle
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Thursday, May 22, 2008 11:48 AM
To: [EMAIL PROTECTED]; Weddington, Eric; [EMAIL PROTECTED];
avr-gcc-list@nongnu.org
Subject: Re: [avr-gcc-list] Avr-gcc Produces Incorrect Code with -Os
You can do
, Eric [EMAIL PROTECTED]
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED];
avr-gcc-list@nongnu.org
Sent: Thu, 22 May 2008 2:33 pm
Subject: RE: [avr-gcc-list] Avr-gcc Produces Incorrect Code with -Os
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent
[EMAIL PROTECTED] wrote:
Eric,
The problem with the function is typical housekeeping overhead gets
wrapped up.
To take a silly example:
Say you want to send some message to ISR (via memory) using critical
function
critical void function(int *buffer, int *cValue)
{
*cValue++ = *buffer++;
http://gcc.gnu.org/onlinedocs/gcc-4.1.0/gcc/Atomic-Builtins.html
David Brown wrote:
[EMAIL PROTECTED] wrote:
Eric,
The problem with the function is typical housekeeping overhead gets
wrapped up.
To take a silly example:
Say you want to send some message to ISR (via memory) using
BTW
I believe the common attribute/keyword for this should be monitor as in
monitor void dostuff(void)
{
putchar ( ’Z’ );
}
This will give a degree of compatibility with other compilers.
David Brown wrote:
[EMAIL PROTECTED] wrote:
Eric,
The problem with the function is typical
-documenting.
Hope this generates some more ideas/discussion,
Scott
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Andy H
Sent: Thursday, May 22, 2008 5:36 PM
To: David Brown
Cc: avr-gcc-list@nongnu.org
Subject: Re: [avr-gcc-list] Avr-gcc Produces Incorrect
PM
To: avr-gcc-list@nongnu.org
Subject: Re: [avr-gcc-list] Avr-gcc Produces Incorrect Code with -Os
Thomas D. Dean wrote:
dtostrf also does not impact the value written to PORTA, so, why does
it not reorder a similar series of statements?
There are several factors that can affect
Hi,
Loveny Design schrieb:
I wouldn't have thought the compiler was allowed to re-order statements
*around* a volatile access. Perhaps someone can help my understanding, given
:-
1: Volatile Statementssp
2: Statementssp
3: Volatile Statementssp
where sp is a sequence point.
Line 3 has a
Loveny Design wrote:
David Brown wrote:
The point is, the compiler is allowed to do this sort of optimisation.
It can be a bit annoying during testing and debugging - especially
because such reorderings are relatively rare in practice, so that it's
easy to think it worked before, what's wrong
On Friday 16 May 2008 08:05:41 am Paulo Marques wrote:
Note! This is not even the worst case for this optimization. The worst
case I've seen is something like:
int my_flag;
cli();
my_flag = 0x1234;
sei();
Contrary to what you might expect, that my_flag access isn't
-Original Message-
From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
org] On Behalf Of Mark Litwack
Sent: Friday, May 16, 2008 9:05 AM
To: avr-gcc-list@nongnu.org
Subject: Re: [avr-gcc-list] Avr-gcc Produces Incorrect Code with -Os
On Friday 16 May 2008 08:05:41 am Paulo
Mark Litwack wrote:
On Friday 16 May 2008 08:05:41 am Paulo Marques wrote:
[...]
Contrary to what you might expect, that my_flag access isn't being
protected by the cli/sei pair, and might be reordered by the compiler
(and might here means it has happened, not some theoretical scenario).
A few random facts:
- accesses to volatiles without intervening sequence points may be
reordered
- accesses to volatiles with intervening sequence points may not be
reordered
- accesses to volatiles may be reordered with respect to non-side
effecting operations (e.g. atan()) regardless of
In my case, I want to allow interrupts, just want to keep the
statement ordering in the code segment.
The PORTA bits are used for hardware control. I want to use the
atan2(), etc. calls as pulse stretching.
Making the resultant variable volatile works.
tomdean
On Friday 16 May 2008 11:32:48 am Weddington, Eric wrote:
Wow. I think the cli()/sei() construct is used fairly
universally, and it's also in the avr-libc docs.
Acutally it's not. What is more appropriate is this:
uint8_t old_sreg = SREG;
cli();
// code
SREG = old_sreg;
You don't
Weddington, Eric wrote:
[...]
If ATOMIC_BLOCK() is *the* way to do it, perhaps the docs
could be improved a little by emphasizing the use of
ATOMIC_BLOCK() as a necessity rather than as a convenience.
I'll go a step further: Is there any reason to NOT include the memory
barrier in the
The PORTA bits are used for hardware control. I want to use the
atan2(), etc. calls as pulse stretching.
Then I recommend using the calls in util/delay.h to get exact delays
instead of monkeying around with floating point routine calls. They'll
be a lot more exact as well as being a boatlad
-Original Message-
From: Paulo Marques [mailto:[EMAIL PROTECTED]
Sent: Friday, May 16, 2008 12:07 PM
To: Weddington, Eric
Cc: Mark Litwack; avr-gcc-list@nongnu.org; Joerg Wunsch
Subject: Re: [avr-gcc-list] Avr-gcc Produces Incorrect Code with -Os
Weddington, Eric wrote
John Regehr wrote:
# define sei() __asm__ __volatile__ (sei ::: memory)
# define cli() __asm__ __volatile__ (cli ::: memory)
snip
Adding these clobbers is an extremely good idea because they make
cli/sei act like proper locks, in two senses. First, they prevent
reordering of
The PORTA bits are used for hardware control. I want to use the
atan2(), etc. calls as pulse stretching.
Then I recommend using the calls in util/delay.h to get exact
delays
instead of monkeying around with floating point routine calls.
They'll be a lot more exact as well as being a
Well, isn't the net effect of volatile simply a more fine-grained clobbering
lock?
Almost but not quite:
- volatile says nothing about the atomicity of any given access
- volatile does not suppress reordering (except with other volatiles)
- volatile has no effect on caches and out-of-order
-Original Message-
From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
org] On Behalf Of John Regehr
Sent: Friday, May 16, 2008 2:17 PM
To: avr-gcc-list@nongnu.org
Subject: Re: [avr-gcc-list] Avr-gcc Produces Incorrect Code with -Os
Finally I'll just add a random plug
John Regehr wrote:
Well, isn't the net effect of volatile simply a more fine-grained
clobbering lock?
Almost but not quite:
- volatile says nothing about the atomicity of any given access
- volatile does not suppress reordering (except with other volatiles)
- volatile has no effect on
Mark Litwack wrote:
On Friday 16 May 2008 04:00:17 pm Dave N6NZ wrote:
[...]
I could see including both clobbering and non-clobbering flavors of
sei()/cli() in avrlibc -- then we can have a whole new and entertaining
argument about whether the old names sei()/cli() should have the new or
old
I have to do the atan2(). It takes a little longer than I would like
the pulse, but, the longer pulse does not hurt anything. So,
including the atan2() in the pulse duration does not waste as much
time as delayxxx() and then do the atan2().
tomdean
The result of the atan2 does not impact the bit value written to PORTA,
so the compiler is free to re-order it. That's what optimizers do.
-dave
Thomas D. Dean wrote:
I have a code segment which
1. sets a bit in PORTA.
2. calls atan2.
3. clears the same bit in PORTA.
The compiler
On Thursday 15 May 2008, Thomas D. Dean wrote:
I changed the code to
asm volatile(sbi 0x14, 4::);
atn_rad = atan2(cos_rad,sin_rad);
asm volatile(cbi 0x14, 4::);
and the compiler still reordered the statements to put both the sbi
and cbi statements before the atan().
Changing
Hi,
if i read:
The code fragment,
...
dtostrf(cos_rad,6,3,line4[14]);
line3[20] = ' ';
line4[20] = ' ';
TRACE_ON(TRACE4); // portb |= _bv(04)
atan_rad = atan2(cos_rad,sin_rad);
TRACE_OFF(TRACE4); // portb = ~_bv(04)
dtostrf(atan_rad,6,3,line4[26]);
portb it looks like
Thomas D. Dean wrote:
I have a code segment which
1. sets a bit in PORTA.
2. calls atan2.
3. clears the same bit in PORTA.
The compiler produces code that
1. sets the bit in PORTA.
2. clears the same bit in PORT.
3. calls atan2.
With -O0, the code is correct.
# uname -a
I changed the variables to volatile and that fixed things.
The compiler does not seem to move things around the
sin/cos/tan/asin/acos/atan functions, only the atan2.
I put the code segment below. I was looking into size/time for these
functions. I saw what I expected around all the functions
38 matches
Mail list logo
