Follow-up Comment #11, bug #30363 (project avr-libc): >> Other than loop/cycle count truncation was the previous way of >> doing things, what is the reasoning for preferring truncation >> to be the new default vs "round up" as the default going >> forward?
It is mostly driven by the previous implementation. >> "round up" as a default would require the user to have to >> define something to ever get a delay that is less than what >> is asked for I think it can be argued either wise - "round up" or "round down". Both have trade-offs. When "round up" is used, the user might end up wondering why delay is a little more than what he bargained for. >> I am worried about delays being reduced or even eliminated >> due to cycle count truncation to 0 or rounding cycle count >> down to 0 because this is creating a different behavior than >> the previous code. >> For example, if somebody called _delay_us(.500) and was >> running on 1Mz clock. Previously they got a 3us delay, but if >> truncation is the default and there is no bump to a non zero >> number of cycles, they would get no delay, which might not >> work. Even if "round up" is used, a clock cycle of '1' is given out for cases where cycle count is 0.*. It is still different from the expected 3 cycle clock. This has to be corrected anyway. How would "round up" solve the situation? or rather how can introducing non-zero delay make any difference? I am open to considering "round up" as default option. However, I am trying to understand the full implication of it, if there is any. >> I'm assuming ceil() is a gcc builtin or >> could be something like this? ceil() is from avr-libc. I planned to re-use available functions for optimization considerations. http://www.nongnu.org/avr-libc/user-manual/group__avr__math.html#ga61470611f23ceef5d3e9cf63d84cd8a7 I'll talk about backward compatibility in next comment. _______________________________________________________ Reply to this item at: <http://savannah.nongnu.org/bugs/?30363> _______________________________________________ Message sent via/by Savannah http://savannah.nongnu.org/ _______________________________________________ AVR-libc-dev mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
