itoa'd you so?
charlescurley at charlescurley.com
Sat Sep 22 07:00:53 MDT 2007
On Fri, Sep 21, 2007 at 11:42:29PM -0600, Levi Pearson wrote:
> Charles Curley <charlescurley at charlescurley.com> writes:
> > I like it. A few points.
> > * It is base ten only. My solution is much more general. Need base 36?
> > Recall that base 10 was not specified in the original problem. But
> > your method can be adapted at the cost of:
> > * expanding the lookup table,
> > * dividing by a variable instead of an inline constant, usually
> > slower.
> Your solution doesn't take 'base' as a paramter, so I can only assume
> you've defined it as a constant global variable somewher else in your
> program. In that case, your solution is just as fixed as mine. The
> modifications to change the base for either are trivial, but require a
You are correct that base is defined elsewhere; it is a global.
Again, this is embedded programming. A calling function can set base
before calling itoa. That's a bit more flexible than adding to your
lookup array, which will be in ROM at runtime.
> > * You have a call to abs inside your main loop. I think I see why, but
> > would you safely speed things up by moving it outside?
> Only after the first iteration. It's there so that it handles INT_MIN
> properly. It's plenty fast, so I see no reason to move it, but you
> could unroll the loop one iteration and not perform the abs() inside
> after that if you needed to.
> > * Your reverse function is nice, but probably slower than strcat
> > because it uses an intermediate variable. But I think you can speed
> > it up considerably by only running for (strlen (s))/2 iterations. If
> > so, it probably would be better than my temporary buffer.
> I think you need to read the reverse function more closely. That's
> precisely what it does.
You are right; I stand corrected.
> > * I replaced my while loop with a do ... while loop, and found (to no
> > great surprise) that it is slower. I didn't check, but I doubt it
> > saved any space because of the way do ... while loops usually
> > compile. That did let me get rid of the 0 special case, making
> > things more elegant. The same might apply here.
> The code I presented is adapted from the K&R C book, as I said, in the
> section on control flow. It was an example of where a do/while loop
> would be handy. :)
Aha, cribbing from the textbook, eh!?
> > * I declared some variables to be register variables. That helps on
> > Intel architecture, which is so pathetically register poor. It might
> > or might not help on register rich processors because the compiler
> > might do it for you.
> I think modern compilers do a pretty good job of optimizing register
> use when you ask them to, and I think they're also free to ignore a
> register declaration. I'm not sure there's any real benefit; you'd
> have to compare asm output to tell.
You are correct that a register declaration is advisory. I agree that
one would have to look at the assembler output. Actually, what I would
do if I were writing this for a real embedded library is look at the
assembler output for several of these versions, pick one or two for
size and speed, and further hand optimize the heck out of that.
> > * I declared the function digit inline. That helped. But it would make
> > for a smaller code size only if digit isn't used elsewhere. It could
> > be a useful routine for special cases like a hex dump.
> Possibly. The compiler ought to be able to inline it without your
> help, though, if you ask it to.
OK. That depends on the compiler, of course.
> I think your program is pretty good now, aside from the fatal flaw of
> not handling MIN_INT properly. That's really not acceptable; it needs
> to be correct more than it needs to be sped up. itoa is pretty much
> never going to be an embedded system bottleneck, but you never know
> when you're going to hit a corner case. Also, on my computer at
> least (1.2 Ghz PPC), my version is still faster.
Fair enough. I think we're down to the point where the actual
application at hand might determine some of our trade-offs. Do we
optimize for speed or size? That depends on whether we are constrained
for ROM space, or for time. Or, Murphy help us, both. Etc.
Charles Curley /"\ ASCII Ribbon Campaign
Looking for fine software \ / Respect for open standards
and/or writing? X No HTML/RTF in email
http://www.charlescurley.com / \ No M$ Word docs in email
Key fingerprint = CE5C 6645 A45A 64E4 94C0 809C FFF6 4C48 4ECD DFDB
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : http://plug.org/pipermail/plug/attachments/20070922/84bf8d3d/attachment.bin
More information about the PLUG