[FFmpeg-devel] lurking bugs in the mmx-related assembler code (?)
george at nsup.org
Mon Oct 3 22:48:47 EEST 2016
Le duodi 12 vendémiaire, an CCXXV, u-9iep at aetey.se a écrit :
> The author of the referred code acts in his actual area of competence
> (C libraries and standards).
> The comments here on the C library code and standard compliance come from
> developers having a different competence area (multimedia programming).
> As bright as the people here are, they land in a foreign area, which
> accidentally leads to statements like the above.
I am sorry, but an appeal to authority will not cut it in front of real
The real argument here is: musl makes several assumptions about the
architecture and compiler (for example: that floats and ints have the same
endianness) that are not mandated by any standard. And although these
assumptions are very reasonable and widely respected, there will eventually
be an architecture or, more probably, a compiler, that will break them.
FFmpeg does exactly the same.
Now, when these assumptions break, who is to blame? One could say that, by
principle, whoever made an assumption not guaranteed by a standard is
guilty, but this is a simplistic approach. More reasonably, the one to blame
is the one who has the worse reason for making the assumption or breaking
In this instance, we know the reason for FFmpeg: resetting the FPU state is
expensive, and this is speed-critical code. Please tell us what are musl's
reasons for using this ugly hack. If the answer is speed, I would very much
like to see a benchmark comparing this implementation to a portable but
optimized log2, especially for x86_32, where int <-> float conversions are
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 801 bytes
Desc: Digital signature
More information about the ffmpeg-devel