On Mon, 19 Jun 2006 02:55:37 -0700 "Mark K. Kim" <[EMAIL PROTECTED]> 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! _______________________________________________ vox-tech mailing list [email protected] http://lists.lugod.org/mailman/listinfo/vox-tech
