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
