[FFmpeg-devel] r9017 breaks WMA decoding on Intel Macs

[Guillaume POIRIER]

Hi,

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

Guillaume
-- 
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")