[FFmpeg-devel] [PATCH] generic infrastructure to support IWMMXT2

Antipov Dmitry dmantipov
Fri May 23 07:09:53 CEST 2008

22.05.08, 23:55, "Siarhei Siamashka" <siarhei.siamashka at gmail.com>:

> Your change actually enforces the use of iwmmxt and iwmmxt2 by default for
> everyone unless it is explicitly disabled with "--disable-iwmmxt*". It is
> different from the logic that has been used so far (I'm not implying that
> the current logic is perfect).

I agree that two (mutually exclusive in most of the cases) types of logic are applicable 
here - a) choose the best automatically, downgrade if user wants and b) follow user's
options strictly, assuming the user knows what's going on here.

I believe that the 'end-user' software should use a) and not b). For example, MPlayer -
being natively configured on x86, it's configure will try to select the best from
MMX/MMXEXT/3DNOW/3DNOWEXT/SSE/SSE2/etc., and advanced user may specify '--disable-THING'.

This patch suspects that FFmpeg is 'end-user' software (:-)), so it tries to follow a).
If the compiler/assembler understands -march=iwmmxt2, let's use it. If not, let's try 
-march=iwmmxt. Advanced user may issue ./configure --help and enable/disable things
according to personal needs.

> This part does not make much sense. The problem was that the toolchain
> actually silently generated wrong code if the user specified "-march=iwmmxt"
> (instead of "-march=iwmmxt2") and this instruction is used somewhere in inline
> assembly code (a bug in HAVE_IWMMXT/HAVE_IWMMXT2 ifdef selection in the code
> or if the user also enforced --enable-iwmmxt2 for whatever reason and it got
> enabled).

This is the problem, really. Actually, we need to run cross-objdump (most probably
it's ${cross_prefix}${objdump}) here to verify that the generated code is correct. 

> If the toolchain is old enough and does not support iwmmxt2 at all,
> it will fail on the iwmmxt2 support check anyway (the part which checks
> for "wavg4" instruction). That is if I understand current situation correctly.

This is another problem. For example, I have two toolchains for now:
 - old, with gcc 3.4.3, configured with '--with-cpu=iwmmxt --with-arch=iwmmxt2
 - new, with gcc 4.2.0, configured with '--with-cpu=arm10tdmi --with-interwork
   --with-arch=armv5 --with-tune=arm10tdmi'

So, the first one is targeted for XScale core with WMMX2 by default - being run without
arguments, it does '-march=iwmmxt2' automatically. But new toolchain needs explicit 
'-march=iwmmxt2' in the command line since it's targeted to another CPU by default.

The problem is that even the old toolchain supports WMMX2 - it passes 'wavg4' test.
But it's broken and can't compile pre-increment expressions:

/tmp/ccC9bIBm.s: Assembler messages:
/tmp/ccC9bIBm.s:23: Error: immediate expression expected -- `wldrd wr0,[r0,r1]!'

So, this piece of configure protects the user who wants WMMX2 from using too old
(and so broken) toolchain.


More information about the ffmpeg-devel mailing list