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

[Michael Niedermayer]

Hi

On Thu, May 31, 2007 at 08:55:01PM -0700, Trent Piepho wrote:
> On Fri, 1 Jun 2007, Michael Niedermayer wrote:
> > On Thu, May 31, 2007 at 05:30:16PM -0700, Trent Piepho wrote:
> > [...]
> > > > so i think you will agree with me that gcc does not gain any knowledge
> > > > of the read/written memory locatons by introducing extra operands in this
> > > > case ...
> > > >
> > > > and in the case that you agree we are back to the original:
> > > > current code (breaks old buggy apple assembler) vs. more operands which might
> > >
> > > And uses incorrect syntax.
> >
> > maybe, its not overly relevant as we will likely not keep that code like
> > it is, but still iam curious, could you quote the part of the manual which
> > says its incorrect?
> 
> 	"Infix operators" take two arguments, one on either side.

1+(%eax)

looks like 2 to me 1 being one, (%eax) being the other


> 
> > > > break with old gcc vs. writing the loop in asm which will be faster,
> > > > more compatible and wont depend on the moon phases when gcc was
> > > > released
> > >
> > > I think you'll find writing that loop in asm to not be so easy.
> >
> > > You'll
> > > need to have a lot of operands to the asm block,
> >
> > no, the 4 arguments passed to the function are sufficient
> > iam not saying it should be implemented like that iam just proofing
> > you wrong ...
> 
> Unless you want to hard code the structure offsets, 

yes that was the idea


> and assume they don't
> change with different compiler options, 

they dont, there is code which does that in for example the swscaler and it
works flawless on many different compilers, different platforms, ...


> you'll need to add some "i"
> arguments for them.  

> If you want to allocate stack space, you'll need to
> make sure that none of the operands uses esp, or you can't access the
> operand while the stack has been moved.  And allocating pointers on the
> stack in an asm block in a way that works on both ia32 and x86-64 will be
> hard to say the least.

theres code which does that in ffmpeg and it works fine not to say
it is extreemly trivial

so, please could you stop with this idiotic trolling and either leave this
thread or work on solving the problem instead of telling us why only your
"solution" would be possible


> 
> > > And since it "might" break with old gcc it's impossible to do it.
> >
> > no even if the above false claims where true this is not true
> > it would have to be tested like any other solution and if it works
> > there would be no problem, or are you arguing that the solution we
> > choose should not be tested?
> >
> > anyway i dont understand why every thread in which you participate
> > degenerates into such trolling
> > may i suggest that you reread your replies and think about the
> > correctness of your statements before hitting the send button?
> 
> I think it's you who must disagree with anything I say, because I'm the one
> who said it.  If the existing code just used two asm arguments when it
> accessed two different elements of an array, and I posted a patch to get
> rid of one and use a "4+%0" displacement, you would argue the exact
> opposite point.
> 
> In fact, I'll do just that, it wasn't hard to find code that does it "my"
> way and change it to "your" way.  It will be interesting to see the mental
> gymnastics you use to prove I'm wrong both times.

?

it breaks on apples assembler so its rejected
not sure what you are trying to proof here except that you dont get it

i say it again
both your solution and the code in svn are bad, the correct solution is to
write the loop in asm, iam constantly repeating this you and constantly
fight on odd war that your change is better than the current code, it
doesnt matter if it is or not as writing the loop in asm is clearly better
than both

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I know you won't believe me, but the highest form of Human Excellence is
to question oneself and others. -- Socrates
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20070601/654c86ed/attachment.pgp>