[FFmpeg-devel] [FFmpeg-cvslog] r15994 - trunk/libavcodec/armv4l/dsputil_vfp.S

[Siarhei Siamashka]

On Wednesday 03 December 2008, M?ns Rullg?rd wrote:
> matthieu castet <castet.matthieu at free.fr> writes:
> > mru wrote:
> >> Author: mru
> >> Date: Wed Dec  3 21:16:01 2008
> >> New Revision: 15994
> >>
> >> Log:
> >> ARM: convert VFP code to UAL syntax
> >
> > Doesn't vfp also present on core without neon (armv5 for example) ?
>
> Yes, but that file only uses VFPv2 instructions.  The machine code is
> the same.
>
> > What's the benefit of using this syntax ?
>
> The instruction mnemonics match those used in the manual.  To me that
> makes a difference.

Still probably it is preferable to use legacy syntax in this file for a few
reasons:
1. Better compatibility with older versions of binutils which do not know
about NEON, but support VFP perfectly fine
2. ARMv5 Architecture Reference Manual uses legacy syntax (it is much more 
easily available for everyone than ARMv7 manual)
3. VFP11 VectorFloating-point Coprocessor Technical Reference Manual uses
legacy syntax (it has VFP11 pipeline description which is good to have when
doing optimizations)

Also I'm curious about the rationale for converting these VFP functions from
gcc inline assembly embedded in .c file into .S file? Having some short
summary of rules/recommendations for doing ARM assembly optimizations in
FFmpeg can help to avoid confusion when submitting patches. You must have some
reasons, but just looking from the outside, the last changes may seem somewhat
chaotic and not always obviously beneficial.

Also we have iPhone users who sometimes try to compile FFmpeg and have
problems: http://www.nabble.com/Compile-FFMPEG-for-ARMv6-td20418745r0.html

It would be nice to have some decision what to do about them. Whether we may
try to improve compatibility of the sources across various versions of GNU
assembler and its clones whenever it is easy to do. For example, '.word'
and '.long' are aliases with the former one not supported by the assembler
from iPhone SDK. Preferring '.long' everywhere can provide a bit better
compatibility with almost no efforts, also it will make the sources more
consistent. On the other hand I would prefer to be able to use such standard
GNU assembler features as ".balign", ".ltorg" and the others (which are
supported by binutils for ages).

I really want to know what GNU assembler features are allowed to be used
before starting to implement VFP11 optimized split-radix FFT.

PS. I already have some VFP11 optimized code for 'vorbis_inverse_coupling'
and 'ff_float_to_int16_interleave' and will try to submit it for review once
all this process of cosmetic source code reshuffling is finished.

-- 
Best regards,
Siarhei Siamashka