> -----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 >
