HS> Bit shifting will ALWAYS be faster than multiplying.
 MW>According to a book I am reading right now. Bit shifting is faster
CD>by a
 MW>factor of around 3 times. You just have to be careful if you shift
CD>too
 MW>far you may lose significant bits. :-(
 HS> My point exactly, you should forward this message to the Chris
CD>Downs.
CD>No.  The point was made that substituting a multiply with two bit shifts
CD>and two adds makes for a performance plus.
CD>The problem is that I've bench marked it.  Counting cycles
CD>is not a satisfactory substitute.  The add/bit shift has more code.  Did
CD>you count the cycles needed to load the code into the instruction
CD>pipeline (for example)???
CD>It's _so_simple_ to get the exact answer by running such a simple test.
CD>I *know* that substituting an bit shifts/adds for an integer multiply
CD>on a 386 is a performance loser.  (Because I tested it) I also know that
CD>substituting a bit shift for a multiply by a constant power of two is a
CD>waste of effort for every compiler I use.  (Again because I tested it.)
CD>Since I don't like to play lose/lose scenarios, I'll pass on the above
CD>advice.  (But I certainly can be swayed by reliable evidence.  How
CD>about bench marking your performace "improvements" and supplying
CD>us with the results??  It would be quite educational!)
i dont even use shifts, i just use a pre-computed look-up table.
... Computer programmers wanted - Some assembly required.
--- Ezycom V1.48g0 01fd016b
---------------