Hi Dmitry, Thanks for looking at this optimization.
I would be interested to know how the algorithm also compares on code size. This is another important metric for avr-libc. And could you please subscribe to the avr-libc mailing list? That way your posts do not have to be approved. :-) Thanks, Eric Weddington > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On > Behalf Of Dmitry E. Oboukhov > Sent: Thursday, June 16, 2011 11:53 AM > To: [email protected] > Subject: [avr-libc-dev] avr-libc: optimization for ltoa/printf > > Hi, There! > > Now avr-libc uses division cycles when it converts number to string. > > Benchmarks page (http://www.nongnu.org/avr-libc/user- > manual/benchmarks.html) > says that ltoa (12345L, s, 10) requires 3174 - 3136 cycles for the > conversions. > > If we use the other algorithm, we can reduce the time more than three > times. > > in attache I placed a test-file that contains 'my_ultoa' function. > > my_ultoa(12345L, s, 10) requires 924 MCU cycles. > against ultoa(12345L, s, 10) - 3174 > > But that algorithm can be realized only for some radixes, so the > function can be used if one of realized radixes is in third argument. > > Also function __ultoa_invert can use the algorithm (it is called from > *printf), so using the algorithm we can spend less time then current > variant. > > The algorithm can be realized for uint, it will more fast. > > Sometimes conversion time is very important (for example if we realize > some text network protocols) so I think that algorithm can be used in > functions ltoa/itoa/*printf :) > > What do You think about this algorithm? > > > PS: sorry for my bad English > -- > > . ''`. Dmitry E. Oboukhov > : :' : email: [email protected] jabber://[email protected] > `. `~' GPGKey: 1024D / F8E26537 2006-11-21 > `- 1B23 D4F8 8EC0 D902 0555 E438 AB8C 00CF F8E2 6537 _______________________________________________ AVR-libc-dev mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
