[FFmpeg-devel] ARM-NEON patches

[Pavel Pavlov]

> -----Original Message-----
> From: ffmpeg-devel-bounces at mplayerhq.hu [mailto:ffmpeg-devel-
> bounces at mplayerhq.hu] On Behalf Of M?ns Rullg?rd
> Sent: Wednesday, July 07, 2010 16:10
> To: FFmpeg development discussions and patches
> Subject: Re: [FFmpeg-devel] ARM-NEON patches
> 
> >> >  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.

I pressed it and the result is
...
> Fixed.
:) the rest isn't important.


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

I know about that. Because native ms tools do not support or capable of generating neon code I'm not worried that some other app uses neon registers. At the same time, it was manufacturers responsibility to adopt the os for their hardware. It's possible that they actually did something and preserve all the registers :) I didn't test, so it could be either way.

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

Well, that was the only possibility and I didn't think that it could be done this way. An application can potentially have thousands of such relocatable symbols that reference thousands of different symbols within the binary and all of them could have some sort of dependency on each other. So, I thought it wasn't done that way.


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


Pic has no meaning on windows or wince I think. Gcc produces some warning about that (something like all code is pic on platform or opposite, I don't remember).

> 
> > How does movw/movt work on elf with function addresses?
> 
> High half in movt, low half in movw.  Easy.
> 

The answer for that question was about loader fixing up executable code at load time.