[Patch,avr] Implement PR56254
Fri Feb 8 17:46:00 GMT 2013
Weddington, Eric wrote:
>> -----Original Message----- From: Georg-Johann Lay Sent: Friday, February
>> 08, 2013 9:00 AM To: Weddington, Eric Cc: firstname.lastname@example.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
>>> compile-time constant, the delay might be overestimated by up to 15
>>> Why would we want to do that? I thought the whole point of a builtin
>>> cycles function was to have an accurate delay.
>> It's not uncommon that users complain that non-constant delays are not
>> 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
>> 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
>> 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.
Ya, you are right. But for the same reason the compiler should not throw an
error if the user wants a non-const delay. It could war, yes, but error() is
IMO either support a feature properly or not at all.
> 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?
This is a patch for gcc, not libc.
libc can define any interface it wants and use, e.g. attribute error, attribute
warning, builtin_constant_p or whatever to wrap around builtin_delay_cycles.
But throwing an error so that the application no more compiles with -O0 is not
nice, i.e. it blocks compiling the stuff for debugging.
Moreover, most applications want a minimum delay, not a maximum delay.
More information about the Gcc-patches