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

[Luca Barbato]

Michael Niedermayer wrote:
> 
> bloat

that was my reasoning, so looks like our point of view is quite different.

> 
> 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?

that w/out nobody would add them for other arches because it would cause
bloat:

5 lines for every major arch and its variant would just grow to pages
quickly: think about blackfin, arm variants, ppc/ppc64 variants,
x86/x86_64, sparc, mips.

5 lines is just an oneliner with 2 ifdefs, do it for most of the arches
and you have already a monster of over a page.

> 
> and ive the same oppinion about the mpegaudiodec asm removial
> MULH is mpegaudiodec specific its not supposed to be a generic macro

When I started moving the asm bits in the dirs there were the call for
factorizing common mathops that could be used across avcodec and that
aren't implemented already or that are almost duplicated. I'm not sure
anybody followed then. Same for bitstream split, that's on hold since
I'm not sure how you'd like better.

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

If instead of MULH you have MUL16H or a MUL3216H nothing should break,
since the macro does exactly what is expected to do, am I wrong?

> 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

The advantage is that other arches have a clean way to implement their
arch specific bits w/out having them scattered across avcodec/avutils
and without stepping on the other toes.

I understand your point of view now, do you understand mine?

lu

-- 

Luca Barbato

Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero