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

[Augie Fackler]

On Jun 1, 2007, at 5:27 AM, Michael Niedermayer wrote:

> Hi
>
> On Fri, Jun 01, 2007 at 11:51:31AM +0200, Guillaume Poirier wrote:
>> Hi,
>>
>> Michael Niedermayer wrote:
>>
>>> so ive came up with the following decissions:
>>> 1. trent please stay out of disscussions related to gnu/elf/pic  
>>> if you
>>>    cannot accept that your views are not shared by the other people
>>> 2. the code should be changed so the loop statements are in asm  
>>> and not
>>>    in C this is the obvious optimal solution
>>
>> Could you explain why this would get rid of the shitty offset+% 
>> pointer
>> syntax? This may seem like a trivial question to you, but this  
>> doesn't
>> seem obvious to me. I'd tend to think that we'd still have to write
>> smth like offset+loop_register+%pointer, or smth like that.

Here's an alternative solution proposed by one of my fellow Perian  
developers (I'm sending it here because that way the threading will  
be maintained, he wasn't subscribed until recently):

The issue was outlined quite well by Michael[1].  Basically, in the  
assembly, they have offset+%number which will translate into things  
like 345+(%ebx,%ecx) or 345+123(%eax).  The second case is fine with  
the gas included in OS X, but the first case seems to barf it up and  
it instead assembles 0(%ebx,%ecx), which is clearly wrong (Linux gets  
it correct though).  One suggestion was to change it to offset% 
number, which will translate to 345(%ebx,%ecx) or 345123(%eax), where  
the first case will assemble just fine, but the second case as  
absolutely wrong (we don't know which case gcc will decide to give us).

My solution is to do offset+0%number which translates to 345+0(%ebx,% 
ecx) or 345+0123(%eax).  In the first case, we add 0 which OS X's gas  
has no issue with and assembles correctly, and the second case, the  
number is given a leading 0, which is still the same number.  I may  
be completely off my rocker here, but I expect this is the real  
solution for use.  Attached is my patch to fix it.

Linux assembly dump:
0x083dd71b <ff_imdct_calc_sse+139>:     movaps (%ecx),%xmm0
0x083dd71e <ff_imdct_calc_sse+142>:     movaps (%ebx),%xmm3
0x083dd721 <ff_imdct_calc_sse+145>:     movaps 0xfffffff0(%ecx),%xmm4
0x083dd725 <ff_imdct_calc_sse+149>:     movaps 0x10(%ebx),%xmm7

OS X assembly dump:
0x15093c15 <ff_imdct_calc_sse+160>:	movaps (%ecx),%xmm0
0x15093c18 <ff_imdct_calc_sse+163>:	movaps (%ebx),%xmm3
0x15093c1b <ff_imdct_calc_sse+166>:	movaps -16(%ecx),%xmm4
0x15093c1f <ff_imdct_calc_sse+170>:	movaps 16(%ebx),%xmm7

Both OS's are correct here.

Thoughts?

- Graham Booker (via Augie Fackler)

[1] http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2007-June/ 
030359.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mactelBrokenGas.patch
Type: application/octet-stream
Size: 2860 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20070602/efd77b01/attachment.obj>
-------------- next part --------------

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20070602/efd77b01/attachment.pgp>