Re: playout garbled in iPhone 3.x Release build (solved)
Re: playout garbled in iPhone 3.x Release build (solved)
- Subject: Re: playout garbled in iPhone 3.x Release build (solved)
- From: Tim <email@hidden>
- Date: Sun, 02 May 2010 15:56:21 -0700
On Sun, May 2, 2010 at 1:45 PM, Tim <email@hidden> wrote:
long bits;
bits += bits; // shift bits left by 1
Overflow? Why not bits << 1?
if( bits >= 0 ) {
// high order bit is 0
}
Why not just (bits & 0x80000000)?
This comes from the old days when I used to look at assembly language.
Arithmetic operations generally set a status register that processor
can branch on. So, the way I did it would typically translate to 2
instructions:
ADD
BRANCH (if result of add is >= 0)
You could do shift instead of add, but add used to be faster than
shift, and adding a number to itself is equivalent to multiplying by 2,
which is equivalent to shifting left by 1. Of course, you generally
want to let the compiler figure out which of those is fastest. This
code was written years ago, and has worked fine a variety of platforms.
If shift is faster than add, then the compiler could change my add to
a shift.
What you suggested would add an unnecessary instruction unless the
compiler was smart enough to remove it, which I think is what it did,
because I did try replacing ( bits >= 0 ) with ( !(bits & 0x80000000 )
) and it did not change the behavior, even though I could plainly see
from print statement the bits satisfied both of those conditions.
Somehow bits = bits + bits; is not setting the status register bits
which the if( ) branch depends on. Or, the branch is incorrectly
evaluating the overflow condition. Probably something to do with
64-bit support.
Tim
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden