[FFmpeg-devel] ARM-NEON patches

[Måns Rullgård]

Pavel Pavlov <pavel at summit-tech.ca> writes:

>> -----Original Message-----
>> From: ffmpeg-devel-bounces at mplayerhq.hu [mailto:ffmpeg-devel-
>> Subject: Re: [FFmpeg-devel] ARM-NEON patches
>> > ELF-attrs.patch : elf specific attributes in arm asm.
>> > ff_dsputil_init_neon_DEPENDS.patch : proper dependencies in arm
>> Makefile. ff_dsputil_init_neon references ff_vp3_idct_XXX functions for
>> vp3, vp5 and vp6.
>> > neon-wince.patch : asm-offsets.h for windows and movrel cannot use
>> > movt/movw for relocatable symbols
>> >
>> >          .word fft65536_neon
>> > -        .size fft_tab_neon, . - fft_tab_neon
>> > +ELF     .size fft_tab_neon, . - fft_tab_neon
>> >
>> The size of things is not an ELF-specific.
>
> I didn't really pay attention

Try paying attention next time you decide to write patches.

> to this part what it was all about, but the error I was getting it
> this place is:

> /ffmpeg/libavcodec/arm/fft_neon.S:367: Warning: .size pseudo-op used outside of .def/.endef ignored.
> /ffmpeg/libavcodec/arm/fft_neon.S:367: Error: junk at end of line, first unrecognized character is `f'

It seems the .size directive has different meanings depending on the
object file format.  Fixed.

>> >  pmmp:   .float  +1.0, -1.0, -1.0, +1.0
>> > Index: libavcodec/arm/simple_idct_neon.S
>> > -        .previous
>> > +ELF     .previous
>> >
>> WTF?  This will put code in the data section.
>> 
>
> Same reason, not really sure what that directive does,

What does this big, red button do?  Let's press it and find out.

> but the error I'm getting is:

> /ffmpeg/libavcodec/arm/simple_idct_neon.S: Assembler messages:
> /ffmpeg/libavcodec/arm/simple_idct_neon.S:246: Error: unknown pseudo-op: `.previous'

Fixed.

>> > Index: libavcodec/arm/asm-offsets.h
>> >
>> >  /* MpegEncContext */
>> > -#if defined(__ARM_EABI__) || defined(__eabi__)
>> > +#if defined(__ARM_EABI__) || defined(__eabi__) || defined(_WIN32)
>> >  #define Y_DC_SCALE               0xa54
>> >  #define C_DC_SCALE               0xa58
>> >  #define AC_PRED                  0xa80
>> 
>> What ABI does wince/arm use?  Besides, these offsets are only used by
>> NEON code, and wince doesn't support NEON, so this shouldn't be needed
>> regardless.
>
> Well, I tried, I compiled and it seems that neon instructions work
> just fine. They aren't os specific, snapdragon cpu is similar to
> cortex-a8.

Wince doesn't do context save/restore on the NEON registers.  Sooner
or later you'll get garbage results.

>> >  .macro  movrel rd, val
>> > -#if HAVE_ARMV6T2 && !CONFIG_PIC
>> > +#if HAVE_ARMV6T2 && !CONFIG_PIC && !defined(_WIN32)
>> >          movw            \rd, #:lower16:\val
>> >          movt            \rd, #:upper16:\val
>> >  #else
>> 
>> Wince doesn't support relocations?
>> 
>
> I don't know how it works in elf, but this kind of stuff isn't
> supported by coff I think. Since movw/movt will have hardcoded
> top/bottom words of the function address it means that the function
> will absolutely have to be loaded at the same address at which
> linker predicted it to be loaded.

No, it means the loader has to fix up the code if it loads it at a
different address.  Perfectly normal stuff.

> It means that the code is not position independent which cannot be
> true on windows: even if there is base address specified os may load
> it at different address.  Executables on wince I think are all
> loaded at the same address, but shared objects share the same
> address space with other processes and therefore if any other
> process occupied somehow address range then the os will load the dll
> at any free base address.

If you need PIC, configure with --enable-pic.  PIC is automatically
enabled with shared libs on ARM, so you're obviously doing something
stupid.

> How does movw/movt work on elf with function addresses?

High half in movt, low half in movw.  Easy.

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