[MPlayer-dev-eng] Improved remove-logo filter

[Michael Niedermayer]

Hi

On Wed, Nov 08, 2006 at 01:13:39PM -0800, Trent Piepho wrote:
> On Wed, 8 Nov 2006, Michael Niedermayer wrote:
> > On Tue, Nov 07, 2006 at 07:38:01PM -0800, Trent Piepho wrote:
> > [...]
> > > > > You have instead dismissed this as irrelevant, and claimed what is
> > > > > relevant is how you think future versions of gcc will work.  At that
> > > > > point it is no longer a discussion of facts, but one of opinions.
> > > >
> > > > you repeated many times how different gcc versions had difficulty with
> > > > specific asm constructs which where working with others, you yourself
> > > > claimed with that that gccs interpretation and implementation of asm
> > > > changes confirming what i said now it doesnt fit into your newly twisted
> > > > argumentation so you claim the opposit
> > >
> > > My argument has always been that my claims about what asm constructs will
> > > work with past and present gcc versions and which will not work are
> > > correct.  Where you have disagreed with me about that, you have been wrong.
> > > When you said that one must use "=&m" to keep a memory operand from
> > > overlapping an input, you were wrong.
> >
> > my argument has always been about the specification of asm in the docs
> > not the limitations of specific implementations
> > asm code in mplayer and ffmpeg must conform to the asm
> > specification in the docs if it does not it is rejected
> 
> The gcc docs specifically say that "+" should not be used with memory
> operands.  Yet lavc has code which uses "+m", 

yes


> in violation of the
> specification in the docs.  

no, "should" is not the same as "must", please look into a english
dictionary if you dont belive me, you can also just
search for "should" in the gcc docs to get a view of what things you should
and should not do ...
also beware that "should not" might not mean the same as the concatenation
of both words translated individually into your favorite language


> So why is that ok?  Because it works, even
> though the docs say not to do it?

the docs do NOT say this


> 
> You said, "if you want an output to not be able to use the same register or
> memory location as an random input then you must use "=&..."."  The gcc docs
> say this too.  Yet I see this code in h264_loop_filter_luma_mmx2:
> 
> asm volatile(
> ...
> "movq      %%mm7, %0       \n\t"
> ...
> H264_DEBLOCK_P0_Q0(%8, unused)
> ...
> : "=m"(*tmp0)
> : "r"(pix-3*stride), "r"(pix), "r"((long)stride),
>   "m"(*tmp0/*unused*/), "m"(*(uint32_t*)tc0), "m"(alpha1), "m"(beta1),
>   "m"(mm_bone)
> 
> Look at that, the code modifies %0 before it uses %8!  According to you,
> this must not be done because %0 could be the same as %8.  Why is this code
> allowed?

because it works and gcc doesnt work with the correct code


>  Who wrote this anyway?

me and loren IIRC


>  I wonder what they were thinking when
> they put "m"(*tmp0/*unused*/) in there?

_IIRC_ i put that there because it became unused due to some optimizations,
then i simply forgot about it


>  Surely you would never write
> something like that? 

iam a human not a machine ...


> When will this be changed to use the required form of
> "=&m"(*tmp0), even though that doesn't compile?

as soon as i find enough time to get tinycc to the point that it can
compile ffmpeg with asm and with speed similar or better then gcc
and considering the code gcc generates this shouldnt be that hard


> 
> > >  "=&m" won't even compile!
> >
> > and past versions of gcc also failed compiling various things in the c
> > standard, still that didnt affect what is valid c and what is not it was
> > just that gcc was broken
> 
> Do you write code that will work on the compiler you have, or code that
> only works on the compiler you wish you had?  With the former, you get a
> working program, with the later, you get a program you wished worked.

ROTFL

no i write code which conforms to the c specification AND which works on
the compiler i have, its something called writing portable code

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

In the past you could go to a library and read, borrow or copy any book
Today you'd get arrested for mere telling someone where the library is