Re: [AD] fixtoi optimization

[Michael Bukin <M.A.Bukin@xxxxxxxxxx>]

George Foot <gfoot@xxxxxxxxxx> writes:

> On Thu, Sep 21, 2000 at 05:25:08PM +0200, Jean-Christophe WILK wrote:
> > This may not be a revolution for Allegro, but
> > replacing
> > 
> > (x >> 16) + ((x & 0x8000) >> 15)
> > 
> > by
> > 
> > ((x + 0x8000) >> 16 )
> > 
> > in the fixtoi function improves its speed by 20-40%.
> > 
> > The two implementations seem to give always the same
> > result (hopefully!)
> 
> The one case when it wouldn't be the same is where x is
> 0xffff8000.  Then x+0x8000 is 0, giving the result 0, where it
> would have been 0x10000.  I'm too tired to realise whether this
> matters much though -- maybe it would be vaguely inconsistent to
> wrap to 0 in this case?  Or is it to be assumed that the return
> from fixtoi is a 16 bit integer?  At worst, it's a pathological
> case I think.

In this case both functions will give 0, because x is signed and will
be sign extended on shifting.  But in case of 0x7FFF|>=8|xxx the new
version will return negative result instead of 0x8000.

Extending this idea:

int fixtoi (fixed x) { return (((x >> 15) + 1) >> 1); }

It gives the same result as old one (tested all values).  My
artificial test shows that inlined versions of all three functions
have the same speed (for this test).  But old version needs more
registers, so there is a reason to switch to new one.

-- 
Michael Bukin