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

[Graham Booker]

On Jun 3, 2007, at 12:11 PM, Trent Piepho wrote:

> On Sun, 3 Jun 2007, Graham Booker wrote:
>> one) seems to assume that the evaluation of the operator is 0 (not
>> the whole expression btw) meaning it evaluates to 0(..).  So, what
>> about offest+1*%number.  The newer gas assumes offset+1*0(...) in the
>> case of no offset in the %number, and the older gas assumes offset+0
>> (...) in the same case.  For both, if the %number contains an offset,
>> then these evaluate to offset1+1*offset2(%register).
>
> That's pretty clever.  Have you tested it with objdump -d to see if  
> the
> disassembled object has the correct offset?
>

Actually, I was using gdb and doing a disassemble, but anyway, the  
mac equivalent (otool -tv) on libavcodec/i386/fft_sse.o yields:
...
_ff_imdct_calc_sse:
00000187        pushl   %ebp
...
00000227        movaps  (%ecx),%xmm0
0000022a        movaps  (%ebx),%xmm3
0000022d        movaps  0x10(%ecx),%xmm4
00000231        movaps  0x10(%ebx),%xmm7
00000235        movlps  (%edx),%xmm1
00000238        movlps  (%eax),%xmm2
0000023b        movlps  0x08(%edx),%xmm5
0000023f        movlps  0x08(%eax),%xmm6
...

Seems correct to me

>> P.S.  Does anyone know a way to force gcc to give me a %number that
>> evaluates to offset(%register)?  I can't seem to get it to test that
>
> Ask for "m" with something that's a stack variable or one of the  
> function
> arguments, you should get "offset(%ebp)" or "offset(%esp)"  
> depending on the
> value of omit-frame-pointer.
>

Ahh, good idea.  Tested on:
             "movaps          %0, %%xmm0 \n\t"   // xmm0 = r0 X  r1  
X : in2
             "movaps          %1, %%xmm3 \n\t"   // xmm3 = X  i1 X   
i0: in1
             "movaps    -16+1*%0, %%xmm4 \n\t"   // xmm4 = r0 X  r1  
X : in2
             "movaps     16+1*%1, %%xmm7 \n\t"   // xmm7 = X  i1 X   
i0: in1

I modified the above code so that %1 was "m"(s) and got:

0000021c        movaps  (%ecx),%xmm0
0000021f        movaps  0x08(%ebp),%xmm3
00000223        movaps  0xf0(%ecx),%xmm4
00000227        movaps  0x18(%ebp),%xmm7

Notice, the offset of 0x8 and 0x18 for the second and fourth  
instructions.  The latter should be 16 bytes later in memory, and it  
is.  Looks like my modifications works.  Tested it on linux, and it  
yielded:
1d7:   0f 28 07                movaps (%edi),%xmm0
1da:   0f 28 5c 24 50          movaps 0x50(%esp),%xmm3
1df:   0f 28 67 f0             movaps 0xfffffff0(%edi),%xmm4
1e3:   0f 28 7c 24 60          movaps 0x60(%esp),%xmm7

Again, looks like it worked.

> If you reqest two "m" inputs, where one is a constant offset from the
> other, it should give you an offset too.  x[i] and x[i+1], or x- 
> >foo and
> x->bar for example.
>
> foo(int i,int x[20]) {asm("# %0 %1" :: "m"(x[i]), "m"(x[i+1])); }
>         # (%eax,%edx,4) 4(%eax,%edx,4)

I actually tried this one, just got a different register :(.  Maybe  
my offsets were just too large when I tried it or something.  Anyway,  
using a "m" on a stack variable worked just fine.



- Graham


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1601 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20070603/e7d4dab4/attachment.bin>