[vox-tech] Reference books (Was: Re: a comment on Pete's fast-loop question

[Jeffrey J. Nonken]

On Mon, 19 Jun 2006 02:55:37 -0700
"Mark K. Kim" <lugod2 at cbreak.org> wrote:

> On Sun, Jun 18, 2006 at 08:13:30PM -0700, Micah J. Cowan wrote:
> [snip]
> > Given your explanation above, you might also find Hacker's Delight
> > to be enjoyable reading (if you haven't read it already).
> 
> Oh I love that book.  I ran into it browsing through the school
> bookstore and *had* to buy it.  I think of the book more of a bag of
> tricks for embedded systems programmers but I have yet to go through
> much of the book yet.  The first trick operation in chapter 2
> (figuring out the rightmost set bit, I think) was one of the IBM
> pre-interview questions a semester or two ago, I heard.
> 
> Another book I refer to for embedded systems programming tricks is
> "Math Toolkit for Real Time Programming" by Jack W. Crenshaw.  Covers
> things like integer square roots and integer logorithms.  It's more
> of an integer operations book for systems with no floating point
> math.  Not really related to what Peter's doing but still cool
> nonetheless.

I'm definitely going to have to look these two books up, especially now
that I have an income. (Part of the reason I haven't been keeping up
with this list, among other things. Not much free time. :)

I'm an embedded systems software developer (once again gainfully
employed as such) and will be interested in some of this stuff, I'm
sure.

As for the trick that started this discussion, I have two things to say.

1) As a number of people pointed out, get it working first, then
optimize. I'll throw another book title at you, "Code Complete 2" by
Steve McConnell. Fascinating book. Making the code work and making it
maintainable is far more important virtually all the time than making
it faster. He's big on maintainability.

2) Since I'm writing assembly on 8-bit machines that need to do a lot
with few resources, I'm afraid that a lot of optimization is done right
along with the development. On the other hand, some tricks are obvious
-- such as, for example, counting backwards from n-1 and checking for
zero, which does actually save doing a separate comparison. On the other
hand, doing it the other way 'round will NOT make assembly language
code a lot more readable. :)

But even there I've done a lot of "make it work first, then optimize
it." There are a lot of little tricks you learn to optimize as you go,
but those become automatic. Such as the reverse counter trick.

But you guys living in the world of desktop computing won't find them
very useful. Better to do a good overall design, get it to work, then
profile, like the man said.

Have fun!