[Top][All Lists]

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

[avr-gcc-list] [Bug] Initialization for _delay_loop_2 Optimized Out

From: Dave Hansen
Subject: [avr-gcc-list] [Bug] Initialization for _delay_loop_2 Optimized Out
Date: Thu, 24 Jul 2003 10:39:18 -0400

Joerg Wunsch wrote:
As "Dave Hansen" <iddw at hotmail.com> wrote:

#define CLOCKS_PER_US   ((U16)(OSC_FREQ/1000000))

You remember that all these calculations are done using the `int' data
type, i. e. a 16-bit one, unless you force it to become long, do you?
So unless your OSC_FREQ macro has an `L' added somewhere, the above
division might become 0.

No.  From n869

"The type of an integer constant is the first of the corresponding list in which its value can
   be represented."

There follows a table showing the resulting types of integer constants. For a decimal constant with no suffix, the list is "int, long int, long long int." So 1000000 is a long, even without the suffix. Same for OSC_FREQ, which, if you look more closely at the supplied code, is 12000000. The division is performed in long arithmetic, and the result (12) is converted to U16.

static inline void
my_delay_loop(unsigned int __count)

Identifiers with leading underscores are reserved (for ``the
implementation'') by the C standard.  Please stay away from them
inside your application, or you might risk a name clash with the
compiler or library.

True. But if you're worried about portability, you might as well scold me for using "asm." As I said in my earlier post, my_delay_loop is an exact copy of _delay_loop_2 (which is part of "the implementation") with some additional code added, and is included as an illustration. It appears to be safe on this implementation (avr-gcc) for the following reasons:

  1) The scope of the symbol is local to the function
2) The function doesn't use the library (though it does use the asm extension)
  3) The implementation does not use the symbol as a macro or keyword
  4) The implementation uses the same symbol in the same manner
  5) The code using my_delay_function *works*.

Which, again, is the whole point of the bug report. I haven't tried it (I don't have the time right now), but I suspect the following:

  #include <avr/delay.h>
  int main (void)

     return 0;

Would generate incorrect code.  Regards,

The new MSN 8: smart spam protection and 2 months FREE* http://join.msn.com/?page=features/junkmail

reply via email to

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