[Ffmpeg-devel] [rfc] arch specific dir in libavutil

[Siarhei Siamashka]

On Sunday 08 October 2006 01:16, Michael Niedermayer wrote:
> Hi
>
> On Sat, Oct 07, 2006 at 07:12:24PM +0200, Luca Barbato wrote:
> > Michael Niedermayer wrote:
> > > rejected
> > >
> > > [...]
> >
> > rationale?
>
> bloat
>
> if we have pages of asm code for various cpus then arch specific dirs make
> sense for the few lines in avutil it does not and anyway whats your
> rational for them?
>
> and ive the same oppinion about the mpegaudiodec asm removial
> MULH is mpegaudiodec specific its not supposed to be a generic macro

It depends on how you define this macro. If it is precisely defined as a high
order 32-bits of 32bit*32bit->64bit multiplication, it should be fine to have
it in a common header file. As this operation is supported by many cpu
architectures efficiently using a single instruction, it may be used in
different decoders and optimized versions of it for different architectures
may be defined in one common header.

> for example where should i apply the arm MULH optimization which
> changes one side to 16bit? if any other part of lavc used MULH
> it would likely break, ok no other part uses it yet but then why is
> it in a header which is not mpegaudiodec specific ...
> these changes make things more complicated while the advantage isnt
> clear to me, the 5 lines of asm in mpegaudiodec.c where hardly a problem

If we are speaking about MULH macro and its functionality, that can be done by
adding a macro with some different name which either uses MULH (for 32-bits)
macro, or implements it in a different way for 16-bits (this requires some 
find&replace changes). But moving MULH to a common header only had any 
sense if several decoders actually had this macro duplicated. There is the
following line in vorbis.c by the way, though it uses unsigned
multiplication: 'temp2=(((uint_fast64_t)temp) * inverse_class)>>32'

And I completely agree about MULL macro - it hardly has any use outside
mpegaudiodec.c code.

My original suggestion was only about 16-bit multiplication which is supposed
to have only a single interpretation and can't be misused:
http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2006-September/045158.html