On 20 April 2006 17:01, Olivier Galibert wrote:
> On Thu, Apr 20, 2006 at 04:52:14PM +0100, Dave Korn wrote:
>> Yet it would seem to me at first glance that, since dividing unsigned by
>> an exact power-of-2 can be optimised to a right shift, and since we can
>> deduce that (1 << bpp) is always going to be a power-of-2
>
> Isn't that true only if bpp is small enough? OTOH, on big bpp we're
> probably straight into undefined territory so it may not matter.
Indeed, the reason that shifting by amounts > word-size # of bits is
undefined is specifically /so/ that these sorts of optimisations can be
allowed without having to code range checks around them.
> But
> still, it changes an expected divide-by-zero on some cpus and
> divide-by-one on others by a zero return, which may be surprising.
Ah, avoiding the danger of divide-by-zero causing an exception/trap may well
turn out to be the reason. Thanks for the thought.
> I suspect the divide-by-shift is hidden behind a bazillion macros,
> right? Only that would explain that a human could write such code :-)
Nope, it's a divide by (2 << function arg). The various constants (32 *
1/2/4) are macros, but the "/ (2 << bpp)" is literal.
cheers,
DaveK
--
Can't think of a witty .sigline today....
