Re: [Patch,avr] Implement PR56254

[Georg-Johann Lay <avr at gjlay dot de>]

Weddington, Eric wrote:
>> -----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.

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
not nice.

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.


Johann