[FFmpeg-devel] ARM-NEON patches

[Pavel Pavlov]

> -----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 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'

> 
> >  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, 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'

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

> >  .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. 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. How does movw/movt work on elf with function addresses?