Package: avr-libc Severity: wishlist Hi, Maintainer!
I can't register or subscribe upstream BTS/maillist. So I would like
If You forward my suggestion them :)
Current variant of the (utoa/ultoa) functions uses division to
translate numbers to string. So it can take a lot of time, see
file:///usr/share/doc/avr-libc/avr-libc-user-manual/benchmarks.html:
itoa (12345, s, 10) - 1172 clocks
ltoa (12345L, s, 10) - 3174 clocks
Radix == 10 can be great optimized if we use the other algorithm.
I've tested a variant such this:
=cut
static const unsigned long digits[] = {
1000000000,
100000000,
10000000,
1000000,
100000,
10000,
1000,
100,
10,
1,
};
char * ultoa10 (unsigned long __val, char *__s) {
unsigned char i, j, k, first = 1;
for (i = j = 0; i < sizeof(digits) / sizeof(unsigned long); i++) {
if (digits[i] > __val) {
if (first)
continue;
__s[j++] = '0';
continue;
}
first = k = 0;
while(digits[i] <= __val) {
__val -= digits[i];
k++;
}
__s[j++] = k + '0';
}
if (first)
__s[j++] = '0';
__s[j] = 0;
return __s;
}
char * ltoa10 (long __val, char *__s) {
if (__val >= 0)
return ultoa10((unsigned long)__val, __s);
__s[0] = '-';
return ultoa10((unsigned long)(-__val), __s + 1);
}
=cut
This variant is more than 5 times faster than libc's ultoa(v,s,10).
So I think it can be used inside the function if radix == 10.
Also this variant can be additionally optimized using PROGMEM
attribute (to reduce RAM overhead).
Also if You use utoa it will have less RAM overhead: 5 * 2
against 10 * 4.
I could create a patch if I knew that it could be applied.
What do You think about this variant?
PS: also if the fucntion __ultoa_invert will be rewritten using the
algorithm, the functions *printf will be faster than now.
--
. ''`. 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
signature.asc
Description: Digital signature
