[FFmpeg-devel] [FFmpeg-cvslog] r15994 - trunk/libavcodec/armv4l/dsputil_vfp.S
Thu Dec 4 01:49:11 CET 2008
Siarhei Siamashka <siarhei.siamashka at gmail.com> writes:
> 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
> 1. Better compatibility with older versions of binutils which do not know
> about NEON, but support VFP perfectly fine
UAL != NEON, even if binutils seems to think so.
> 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.
I find gcc inline assembler more difficult to read and work with.
Separating it also allows FFmpeg to be built with the ARM RVCT
compiler, which gives faster code.
> Also we have iPhone users who sometimes try to compile FFmpeg and have
> problems: http://www.nabble.com/Compile-FFMPEG-for-ARMv6-td20418745r0.html
I don't care about that. Nobody is stopping them using a modern
binutils version. The version in that SDK is completely useless by
the looks of it.
> 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.
I would say anything supported by binutils 2.19 is permissible. I
can't think of any reason to keep using an older version.
mans at mansr.com
More information about the ffmpeg-devel