[FFmpeg-devel] ARM-NEON patches

Måns Rullgård mans
Thu Jul 8 01:26:37 CEST 2010


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

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

What if someone else follows the same logic, and you end up with two
apps sneakily using NEON at the same time?  Even if that doesn't
happen, there's the possibility of the CPU going into power-down sleep
mode at any time, requiring a full context restore on wakeup.  If that
happens while you're holding data in the high NEON registers, said
data would be corrupted.

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

I'm pretty sure they don't.

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

It's the same CPU so of course it has a meaning.  If Windows doesn't
support non-PIC, that's another story.

> Gcc produces some warning about that (something like all code is pic
> on platform or opposite, I don't remember).

Until someone provides me with accurate information on this situation,
I suggest using --enable-pic.  This makes all code, even the assembler
parts, position-independent.

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



More information about the ffmpeg-devel mailing list