[Patch,avr] Implement PR56254

Weddington, Eric Eric.Weddington@atmel.com
Fri Feb 8 17:25:00 GMT 2013


> -----Original Message-----
> From: Georg-Johann Lay 
> Sent: Friday, February 08, 2013 9:00 AM
> To: Weddington, Eric
> Cc: gcc-patches@gcc.gnu.org; Denis Chertykov; Joerg Wunsch
> Subject: Re: [Patch,avr] Implement PR56254
> 
> Weddington, Eric wrote:
> 
> >
> > What does this do? How does it work?
> >
> > Could you explain the statement in the documentation "if ticks is not
> a
> > compile-time constant, the delay might be overestimated by up to 15
> cycles".
> > Why would we want to do that? I thought the whole point of a builtin
> delay
> > cycles function was to have an accurate delay.
> 
> It's not uncommon that users complain that non-constant delays are not
> supported.

Agreed.
 
> It works that same way like const delays except that no constant has to
> be
> loaded and the delay is not 100% exact, i.e. might be up to 15 ticks
> too slow.
> 
> For delays like 100000 it does not matter whether or not it is 15 ticks
> longer,
> most crystals are not exact enough you'll ever notice the difference.

True.

> IMHO, using delays in a application is a design flaw in the first place
> (except
> for very short delays to wait for slow I/O), but the users want it, as
> you know
> very well.

It is not necessarily a design flaw. We cannot judge someone else's application in that way.

And this is what I have a problem with: As you said, most of the time users will implement a very short delay waiting for I/O. It is exactly these short delays where being 15 cycles too slow will have the biggest impact, as it is a bigger percentage of the overall time being delayed.

We already have variable delays in avr-libc. How does this patch solve an existing problem? Does this patch make it more accurate than avr-libc?

Eric
 
> 
> In cases of variable delays the inexactness comes from computing the
> amount of
> ticks at run time, not __builtin_avr_delay_cycles itself.  But that's
> up the
> user that calls __builtin_avr_delay_cycles, it's not a problem of
> __builtin_avr_delay_cycles.
> 
> 
> Johann
> 



More information about the Gcc-patches mailing list