[FFmpeg-devel] r9017 breaks WMA decoding on Intel Macs
Thu May 31 10:10:04 CEST 2007
castet.matthieu at free.fr wrote:
> Quoting Guillaume POIRIER <poirierg at gmail.com>:
>>> This won't assemble correctly if any of the memory operands already have a
>>> displacement. Loren explained why:
>> I agree. This patch's main purpose is to show how to write this
>> routine with proper syntax
> No, it is broken if you aren't lucky (ie the offset is positive).
NO! Read the message I posted on Date: Wed, 30 May 2007 00:28:58 +0200
with the dissasm.
Here's a snippey:
1bd: 0f 28 02 movaps (%edx),%xmm0
1c0: 0f 28 19 movaps (%ecx),%xmm3
1c3: 0f 28 62 f0 movaps 0xfffffff0(%edx),%xmm4
1c7: 0f 28 79 10 movaps 0x10(%ecx),%xmm7
000001d7 movaps (%ebx),%xmm0
000001da movaps (%edi),%xmm3
000001dd movaps 0x00(%ebx),%xmm4
000001e1 movaps 0x00(%edi),%xmm7
As you can see _all_ offsets (both positive and negative, note that
0xfffffff0 is -16) are discarded.
>> (Bear in mind that all assemblers produce a
>> warning here. To a certain extend, we may consider that the reason it
>> works with FSF AS is just by pure luck.)
> Well that's more like a gas extension that was made for case like that.
Maybe, but even on MacIntel, it's GAS. It's just based on an older
version that supports Mach-O:
Apple Computer, Inc. version cctools-622.5.obj~13, GNU
assembler version 1.38
>> But IMHO, it's a bit pointless, because
>> whatever the speed figures may look like, we are comparing 1 solution
>> that appears to work by luck, and another that is more reliable. Speed
>> isn't what your patch is after.
> There is no luck in the old solution providing :
> - we tell gcc the memory we modify (may be using "memory" clobber).
> - we use a gas supporting the +(%reg) syntax
I disagree. Newer gas _do_ complain about the syntax, and Trent
already explained the shortcomings of current implementation, no need
for me to restate them here.
More information about the ffmpeg-devel