[FFmpeg-devel] lurking bugs in the mmx-related assembler code (?)

[Nicolas George]

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
arguments.

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
it.

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
very expensive.

Regards,

-- 
  Nicolas George
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20161003/53e8ea6f/attachment.sig>