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

[Måns Rullgård]

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

-- 
M?ns Rullg?rd
mans at mansr.com