On Saturday 03 March 2007 07:57, Eric Weddington wrote: > > Today, there is a bit of functions (memset, memcpy and > > memcpy_P), which are in 2 variants: compact and speed. > > This acceleration is very effective: a few of progmem > > words give 10..30% speed increase. I plan to expand this > > function list slightly. > > > > Avr-libc compiles a speed variant for avr3 family only. > > What about to add avr5? Is there any objections? > > Hi Dmitry, > > This brings up the overall issue of what should the goal be for avr-libc? > Speed, or size? > > I still lean towards *size* as the number 1 priority for all code, for all > architectures and devices. When AVR compilers are compared, they are always > compared on code size, not code speed.
OK, I shall not change any compilation options. Though a discrepancy remains between avr3 and avr5. Nevertheless, I shall a little expand the list of functions where this option is present. Certainly, it can affect a code only in case of compulsory inclusion of this option. I shall repeat, that it is a question only of small quantity of functions which it is often enough used and where such optimization is effective enough. For example (not commited now): memset: 3.5 vs 6 clock/byte, cost= 4 words memcpy,memmove: 5.5 vs 8 clock/byte, cost= 5 words memcmp: 7.5 vs 10 clock/byte, cost= 6 words strlen: 4 vs 5 clock/byte, cost= 2 words I would not be so categorical in an estimation of a priority of the size. Eventually, speed is important from the very beginning of the project, and the size starts to interest only after overflow of memory. Dmitry. _______________________________________________ AVR-libc-dev mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
