>>
>> Hello,
>>
>> I am sending new patch set with the implementation of fixed point AAC
>> decoder.
>>
>> Most of the requests from review of float emulation done by Reimar are
>> integrated in this patch set.
>
>That at least doesn't include the comments I made on float_add and
>float_gt implementations.
>The former still is horribly complex with no explanation for it,
>and the later still doesn't even mention it won't work for negative
>numbers.
I missed to put a comment regarding float_gt working only for positive numbers
and why, sorry.
I'll resend a patch with this comment.
Regarding your comments on complexity of float_add, the only optimization that
I see in this last version that is truly worth is to return a (or b) in case
if(diff>=31) (or if(diff<=-31)) and I'll change patch to accommodate this.
Regarding combining the >= 31/ <= -31 checks with the checks for 0, it can be
done only for >= 31 because if something like this is done:
if (a.mant == 0 || diff <= -31)
return b;
if (b.mant == 0 || diff >= 31)
return a;
there would be some invalid results. For example it would always return b if
diff <= -31 even if b.mant == 0.
And even if diff >= 31 is combined with b.mant==0, it would reduce number of
branches in else part of if diff<0, but case where b operand is 0 would be
worsened.
As you pointed out, there is a question whether it's more important performance
wise to optimize the case where one operand is 0 or to reduce the number of
branches.
Since purpose for creating this emulation was only to support fixed point
operations in aac fixed point decoder in case when dynamical range is to large
for them, I think that it does not really meter.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
