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

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

RE: [avr-libc-dev] [bug #28881] nop() macro for NOP instruction


From: Weddington, Eric
Subject: RE: [avr-libc-dev] [bug #28881] nop() macro for NOP instruction
Date: Sun, 14 Feb 2010 01:22:13 -0700

 

> -----Original Message-----
> From: 
> address@hidden 
> [mailto:address@hidden
> org] On Behalf Of Joerg Wunsch
> Sent: Saturday, February 13, 2010 1:27 PM
> To: address@hidden
> 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




reply via email to

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