> -----Original Message----- > From: > avr-libc-dev-bounces+eric.weddington=atmel....@nongnu.org > [mailto:avr-libc-dev-bounces+eric.weddington=atmel....@nongnu. > org] On Behalf Of Joerg Wunsch > Sent: Saturday, February 13, 2010 1:27 PM > To: avr-libc-dev@nongnu.org > Subject: Re: [avr-libc-dev] [bug #28881] nop() macro for NOP > instruction > > As Weddington, Eric wrote: > > > I agree that there is not a convenient place to put such a > > macro. But I would also argue now that we do not need to have such a > > macro in avr-libc. The only use for the NOP instruction is for some > > sort of delay, typically by a specific number of cycles. > > Well, there are situations where you have to delay for just a single > cycle (e.g. if you're setting a port output, and want to read back an > input that depends from it). Sure, it's possible to use > __delay_cycles(1) but most people probably find it more "natural" to > just insert a single NOP there. > > Maybe we could add something like <avr/cpufunc.h> or such.
Well, that's my point. I would rather they use __builtin_avr_delay_cycles(1) (the real name of the function), so they get familiar with using it, rather than thinking in terms of what instruction name (like NOP) they should use. The __builtin_avr_delay_cycles(x) function will generally be more efficient; A user may say "I want to delay by 2 cycles, so I'll use 2 NOP instructions", when in reality, the __builtin_avr_delay_cycles(x) function will generate a single "RJMP ." (2 cycles) because it is more space efficient. The point is if the user is interested in writing assembly instructions for their own sake, then they should use the inline assembler capabilities of GCC. If they want just want to delay X number of cycles they should just simply use the built-in function and let the compiler do its job. Eric _______________________________________________ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
