[PATCH] unify itoa

[Denis Vlasenko]

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:
	sprintf='12345678' count=27346
	utoa_to_buf='12345678' count=69880
	utoa='12345678' count=65934

A few days ago I ran "hexdump | grep" over entire hard drive.
Took a long time. I wish hexdump was optimized a bit better...

> > > > gcc optimizes it out to simple 1000000000 constant
> > > > (if sizeof(unsigned)==4, that is).
> > >
> > > When is sizeof(unsigned) not going to be 4 on any Linux platform?  We use
> > > the lp64 model (as do all modern Unix variants, including MacOS X), where
> > > only long and pointer are 64 bit.
> > >
> > > 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.

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.

IIRC Alpha took a simpler "we are a fully 64 animal"
route. Sane C ABI on such CPU should use 64-bit ints,
or else you will drown in zillions of "n &= 0x00000000fffffffff"
type instructions which will enforce 32-bitness
on 64-bit CPU.

I think I'm starting to waste your (and my) time.
Alpha is almost history now...

> > > > So, do you want me to
> > > >
> > > > a) remove #ifdef NOT_NEEDED_YET part
> > > > 	or
> > > > b) enable it and use it in ash?
> > >
> > > The first, please.
> > >
> > > A general rule of thumb: we can always add code to the tree later.  (And
> > > if we remove it, we can always add it _back_ later.)
> >
> > See attached patch.
> 
> Well, it's definitely an improvement.  However, it would be nice if you could 
> call itoa on a buffer and have it actually fill in that buffer from the 
> start, so you could use it like you could sprintf or strcpy, and not 
> potentially have to track two pointers to your own buffer.

That will need either a clever method to determine how much digits are there
_before_ we do the conversion, or copying the result.
I hope that in most cases you can just

	do_something(utoa_to_buf(n, buf, sizeof(buf));

(Actually, im most cases people will just use do_something(utoa(n)); ...)

> I did a quick stab at that and checked it into xfuncs.c, and now I'm about to 
> pass out.  Could you tell me if that's useful, or if not what did I screw up?  
> I have to go fall over and pass out now, it's 4 am and I have work in the 
> morning...

Aha! So you DO have a clever method! :) Thanks!

Hmmm.... (/me takes a look) I think I can improve on that.

Please see (and run) attached program. utoa_to_buf_rob is your version
copied from xfuncs.c. Two problems: it's almost as slow as sprintf
and it doesn't check for buflen. utoa_to_buf_rob2 is a speed improved
version and utoa_to_buf_rob2_with_check adds compile-time check
that unsigned is really 32-bit and also correctly handles buflen.

There is a correctness tests for utoa_to_buf_rob2_with_check.
Seems to work right.

Please put utoa_to_buf_rob2_with_check code into xfuncs
(unless you find more way to make it better).
--
vda
-------------- next part --------------
A non-text attachment was scrubbed...
Name: itoa_bench.c
Type: text/x-csrc
Size: 3950 bytes
Desc: not available
Url : http://lists.busybox.net/pipermail/busybox/attachments/20060710/9aebbade/attachment.c