[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [avr-gcc-list] Speeding [u]ltoa by 35%

From: Georg-Johann Lay
Subject: Re: [avr-gcc-list] Speeding [u]ltoa by 35%
Date: Sun, 15 Jul 2012 14:02:07 +0200
User-agent: Thunderbird (Windows/20100228)

Dmitry schrieb:

3. This is debatable: run time radix check. The cost is
only 5 words, but there is no risk of overhead in case
variable radix. Thoughts?

I'd prefer a compile-time test on C level over a run-time
test at asm level.

The vast majority of user code will come with a radix known
at compile time, so that a compile-time check will help code

Variable radices will be rare, and if one is used the overhead of
not-optimized-out-C-Code-test code size difference compared to the
5 assembler instructions can be justified IMO.

Also notice that the C solution only needs to load an 8-bit
radix whereas the asm-test needs a 16-bit radix as imposed by
the interface.

This also applies to the 16-bit case of {u|i}toa where we have
roughly new:old = 68:66.

If we take into account that the new version together with
C-sanity test for radix saves one instruction compared to
the old implementation, code size of the new version does
not increase and is exactly the same as the old size!

Notice that all this is under the assumption that the application
already uses __udivmod{h|s}i4. If it doesn't, the new version
clearly wins against the old one, both with respect to
speed and size :-)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]