[PATCH] unify itoa

[Rich Felker]

On Mon, Jul 10, 2006 at 11:46:46AM +0200, Denis Vlasenko wrote:
> On Monday 10 July 2006 09:43, Rob Landley wrote:
> > > Examples of things which should care about it
> > > (I do not claim that current code cares):
> > > od, seq, uniq -c, tcpdump, hexdump...
> > 
> > How many of these users actually need a malloc, and how many is it essentially 
> > a better sprintf?
> 
> The attached test program shows that snprintf is 2.5 times slower
> than utoa. Operations done per second:

Which snprintf? glibc? uClibc?
Anyway I ran the rest (after sanitizing it; your benchmarking method
is not valid due to multitasking) and obtained much more extreme
results.

Still your code is huge massive bloat to do something very simple...
It's like these 10k memcpy implementations...

> > > > http://www.unix.org/whitepapers/64bit.html
> > >
> > > What about Alpha? I heard that it has (had?) sizeof(int)==8.
> > 
> > A) Not on Linux.  Linux standardized on LP64.
> 
> I am not sure. It looks like you are not sure too.
> 
> > B) If it's that broken, I don't care.
> 
> What's broken about it? If the CPU is _designed_ to handle
> mostly 64-bit operands, then it's only natural to make
> "int" type 64-bit.

And this cpu won't be able to handle lots of real-world tasks in C
code. Lovely. The conclusion: the cpu sucks.

> For AMD64, instructions are 32-bit (with auto sign extend
> to 64 bit) unless you add a "I want 64bit op" prefix.
> IOW: AMD64 CPU most of the time works with 32bit operands.
> That's why for AMD64, natural size of "int" is 32 bits.
> Cool, AMD got best things from both worlds.

Actually I think the prefix is needed for 32bit when running 64bit
code, but it makes little difference to performance.

> IIRC Alpha took a simpler "we are a fully 64 animal"
> route.

No, it took the "we are an idiotic risc arch" approach of not having
opcodes to manipulate all integer sizes up to and including the system
word size.

> Sane C ABI on such CPU should use 64-bit ints,

gcc is not sane then. :)

> or else you will drown in zillions of "n &= 0x00000000fffffffff"
> type instructions which will enforce 32-bitness
> on 64-bit CPU.

I suspect it's easier than this. Still ugly, and still alpha's fault.

> Please put utoa_to_buf_rob2_with_check code into xfuncs
> (unless you find more way to make it better).

Calling sprintf makes it better by adding less size to BB...
At the very least this should be a build option.

Rich