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

[Dmitry E. Oboukhov]

>> 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

> Yes, but how many cycles does "my_ultoa(99999L, s, 10)" require and how
> does that fare against the standard ltoa(99999L, s, 10)?

I've tested the worst case ((ulong)-1) and 3999999999, it takes near
1200 MCU.
also if we will use two tables: word upto 2^16 and dword upto 2^32
it will take less time.

In attache optimized variant:
my_ultoa(12345L, s, 10)

takes less than 500 MCU and 3999999999 takes less than 1000

>> 
>> What do You think about this algorithm?

> I'm concerned that it might perform badly for very small numbers
> compared to the regular ltoa. Also the fact that the time taken by the
> algorithm depends a lot on the number (i.e. 99999 takes longer than 11111).

> Attached is a version (that I didn't even compile test, to be honest)
> that should alleviate the last problem a little and be faster in the
> average case, but it is even larger than the original version. It only
> works for bases up to 16, though.

I'll look through Your code :)

-- 

. ''`.                               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

dtoa.c
Description: Text Data

signature.asc
Description: Digital signature