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: Kyle Sluder <email@hidden>
- Date: Sun, 2 May 2010 22:28:55 -0700
On Sun, May 2, 2010 at 8:58 PM, Tim <email@hidden> wrote:
> However, from what I could gather at that site, the shift operator is also
> considered an arithmetic operation? So the fact that using x <<= 1 fixes it
> was just good fortune. I think the better fix is:
You are correct, bit-shifting the signed value would be a bad idea for
the same reason.
>
> unsigned long x; // make sure overflow behavior is well defined
> x <<= 1; // let compiler convert to ADD if that is faster than shift
> if( ((signed long)x) >= 0 ) { // test high bit
> printf("hi bit is not set");
> }
This is also bad, but not as bad as before.. See
https://www.securecoding.cert.org/confluence/display/seccode/INT31-C.+Ensure+that+integer+conversions+do+not+result+in+lost+or+misinterpreted+data
where it quotes C99. At least it's implementation-defined, rather than
undefined behavior. GCC's documented implementation is here:
http://gcc.gnu.org/onlinedocs/gcc/Integers-implementation.html#Integers-implementation
So your implementation works for GCC; what about for the other
compilers you use to target your other platforms?
> I know, you would recommend more direct use of bit field operators, but the
> last time I looked at implementations, they were incredibly slow, aimed at
> random access, not marching through a stream of bits sequentially. And,
> then I may have a whole new family of bugs to investigate due to the CPU not
> being able to keep up. So, yeah, don't waste time on pre-mature
> optimization, but if it's already done and it works, no reason to throw it
> out. I need to achieve real time performance on mobile devices with
> relatively slow CPU's (some lower end than iPhone), and every wasted CPU
> cycle is burning battery.
Since CPU and battery are a concern, I assume you are taking advantage
of your optimizer, which will analyze your code and hopefully detect
multiple sequential accesses to bits in the bitfield. This is not an
uncommon operation to perform.
Have you compared the optimizer's results to your own methods? Have
you considered, since you will perhaps need to account for
implementation differences, writing the assembly yourself and avoiding
the whole issue?
"If it's already done and it works" is the enemy of refactoring.
Refactoring produces better systems.
--Kyle Sluder
_______________________________________________
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