Mail Archives: djgpp/1997/02/01/00:04:20
On Fri, 31 Jan 1997 16:52:03 -0500 (EST) mharris AT blackwidow DOT saultc DOT on DOT ca
writes:
>On Tue, 28 Jan 1997, Benjamin D Chambers wrote:
>
>>
>> On Tue, 28 Jan 1997 20:30:34 -0500 DJ Delorie <dj AT delorie DOT com>
>writes:
>> >
>> >> function. Anyway, here's my problem; To my understanding the
>> >following
>> >> are 100% equal:
>> >>
>> >> other_stuff = stuff / 256;
>> >> other_stuff = stuff << 8;
>> >
>> >The second multiplies. Try ">> 8" instead.
>> >
>> >
>> Also, just to be clear, the first gets translated into the second
>when
>> compiling with optimizations on (-O2).
>> In fact, I believe *ALL* integer multiplication/division by a
>constant
>> gets converted to shifts when using -O2, so you might as well use
>the
>> first - if for nothing else then for readability's sake.
>
>If *ALL* integer mults/divs are converted to shifts, then what would
>be the equivalent for:
>
>other_stuff = stuff * 57
>other_stuff = stuff << ???
>
>The point I'm trying to make is that no, only mul/div's by powers of 2
>would be converted to shifts. Others such as multiplying by numbers
>whose factors are of powers of 2 can also be optimized in this way.
>Numbers that don't fit (such as 57) can't be implemented via shifting
>and be optimal.
Uh, yeah?
Write 57 in binary...
111001
On a 486, that's 3 shifts and 3 adds, that's 9 cycles... Can you make a
mul do that?
On a pentium, you should be able to do that in 4 cycles (with 2 stalls on
the V-pipe, so throw in some more code...). That don't beat the pants
off an integer mul?
The catch is that you _HAVE_ to know the multiplier at compile time, so
it can only be done sometimes.
...Chambers
- Raw text -