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
FreeBSD dv6000.tddhome
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
