Re: [avr-libc-dev] avr-libc: optimization for ltoa/printf

[Weddington, Eric]

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: address@hidden
> [mailto:address@hidden On
> Behalf Of Dmitry E. Oboukhov
> Sent: Thursday, June 16, 2011 11:53 AM
> To: address@hidden
> 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: address@hidden jabber://address@hidden
> `. `~'              GPGKey: 1024D / F8E26537 2006-11-21
>   `- 1B23 D4F8 8EC0 D902 0555  E438 AB8C 00CF F8E2 6537