>On Thu, Oct 09, 2014 at 12:02:26PM +0000, Nedeljko Babic wrote: >> > >> >softfloat uses "if (a.mant + 0x40000000 < 0)" to normalize >> >0x40000000U + 0x40000000U is < 0 for int32 and thus not part of the >> >range though -1 would be, is that a problem ? >> >we could use a.mant + 0x40000000 <= 0 in that case >> > >> >the main difference i see to aac is that it shifts up if its too small >> >while softfloat shift down when its too large >> >> The main problem is exactly in difference of handling too large and too small >> values. >> If we must use code from softfloat as is, it will demand a lot of changes in >> aac implementation. >> >> And there are other problems with softfloat: >> - Normalization done for av_add_sf (and av_sub_sf), av_normalize1_sf, is not >> ok. >> It's the same normalization used in multiplication and it will not handle >> normalization of mantissa and exponent correctly after addition. >> On the other hand, av_normalize_sf can not be used as is since it would >> have >> infinite loop for a.mant == 0. >> - I guess we would have a problem with av_div_sf since it needs for b to be >> normalized and it doesn't handle division by zero (also I am not sure about >> precision). >> >> We need functions that are implemented just in our emulation (like sincos >> for example) and not in softfloat and I guess (but am not sure atm) that some >> of them would also need to be changed if we need to use assumptions from >> softfloat. >> >> > >> >both dont implement rounding correctly >> >> We use this rounding for simplicity. On our test cases we do not have >> significant problems with it (overall max 3 bit difference with floating >> point code), although we can change it if it proves to be necessary. >> > >> My question still remains: should we use our float emulation and just >> integrate it in softfloat adjusting it where necessary, or should we use >> softfloat and adjust our aac implementation? > >its ok to integrate your code in sf / change sf as long as it doesnt >remove optimizations or make future optimizations hard > >thanks
Ok. I'll will then recreate this patch and I'm thinking of rebasing all the patches since I see there were some changes that affect our implementation. I will resend entire patch set for review afterwards. Thanks -Nedeljko _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
