[FFmpeg-devel] r9017 breaks WMA decoding on Intel Macs
Wed May 30 08:35:51 CEST 2007
On 5/30/07, Trent Piepho <xyzzy at speakeasy.org> wrote:
> > On Wed, 30 May 2007, Guillaume POIRIER wrote:
> > On 5/29/07, Zuxy Meng <zuxy.meng at gmail.com> wrote:
> > > These warnings comes from the assembler not the compiler about cases
> > > like 16+(%esi). The FSF as treats this as equivalent to 16+0(esi) ==
> > > 16(esi) (therefore the assumed 0). If the Apple as treats it
> > > differently without even a warning then the result is catastrophic...
> > >
> > Linux:
> > 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 clearly see, that damn OSX manage to loose the offset.
> > Zuxy, do you know another syntax than the one you suggested, that
> > wouldn't confuse OSX's assembler?
> Doesn't my patch fix this? That would be the alternate syntax that doesn't
> confuse the assembler.
Yep, your fixed patch does fix the problem (I said that earlier BTW ;-) ).
Now that we know where the problem comes from, I was just wondering if
there wasn't a simpler, less-invasive way. (not that your patch is
unbearably longer, but based on the analysis I made of the
disassembled code, it leads to more code, so I'd expect your patch to
be slower (that, off course, would have to be benchmarked).
Y'a pas de gonzesse hooligan,
Imb?cile et meurtri?re
Y'en a pas m?me en grande Bretagne
A part bien s?r Madame Thatcher
-- Renaud (sur "Miss Maggie")
More information about the ffmpeg-devel