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

[Michael Niedermayer]

Hi

On Sun, Nov 05, 2006 at 01:37:35PM -0800, Trent Piepho wrote:
[...]
> > and copying variables onto the stack can improve speed alot, gcc svn does
> > this according to uoti, maybe violating your dont copy constraint?
> 
> It sounded to me like what Uoti found was an asm construct that modified a
> variable through a pointer with out telling gcc about it.  Something like:
> 
> int x, *p = x;
> asm("movl $0, (%0)" : : "r"(p));
> 
> Of course something like that will not work, because gcc doesn't know the
> value of x has changed.  It needs "memory" on the clobber list, or better
> yet, "=m"(x) as an output.

"=m" needs an additional register in some cases (the ones where no not
modified register points to it or to a constant offset from it)


[...]
> > > > > > > Did you read the same thread I did?
> > > > > > >
> > > > > > > "=m"(x) : "0"(y)  isn't allowed, as a and b can't be in the same location.
> > > > > >
> > > > > > I'm not sure exactly what you're arguing for in here and the rest of
> > > > > > your message, but I think it's not about the same thing as your original
> > > > > > disagreement with Michael.
> > > > >
> > > > > Michael said don't use [out]"=m"(a):[in]"m"(a), use [out]"=m"(a):[in]"0"(a)
> > > > > or [inout]"+m"(a).
> > > > >
> > > > > This is wrong.
> > > > >
> > > > > First, the form with the "0" will not always work properly.  gcc (> ~3.5)
> > > > > will give you a warning if you even try.
> > > >
> > > > it will not give a warning on "+m" which was said to be the same as "=m"/"0"
> > > > by at least one gcc developer in the thread you linked, furthermore if gcc has
> > >
> > > I'm sure you are reading that wrong.  "+m" has been made the same as "=m":"m".
> > > It has not been made the same as "=m":"0".
> >
> > you really seems to be intentionally trying to sidestep the issue, its not
> > what gcc does, it is what something means and what its guranteed to do, its
> > a question of specification vs. implementation
> 
> Suppose the docs are not some kind of specification that the inline asm
> extension was written to follow, but the other way around.  That the inline
> asm extension is just a way to access gcc's internal structures.  That the
> docs are just an attempt to document how to make use of gcc's internal
> workings.  Have you considered that?  Maybe future versions of gcc will not
> have an asm extension that works differently, but different documentation?

as the gcc developers can change both gcc and the docs at will they could 
of course do anything, if changing well written and logic docs to match
the current limitations of the implementation is wise or professional
is another question but they of course could do it


> 
> IMHO, this whole discussion of specification vs. implementation is you
> trying to side-step the issue.

if you see it that way so be it, we cannot rewrite all asm to match a
possibly changing implementation, our asm matches the specification(=gcc docs)
if the asm gcc docs are changed then we will likely put some effort in finding
alternatives to gcc which have a more stable asm specification until then
future gcc versions wont be supported if they fail with our code
this isnt a big issue considering the amount of improvments since gcc 2.95


[...]
> You no longer seem to trying to argue that I'm wrong with respect to how
> past and present versions of gcc work. 

no i do have better things to do


> 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


> 
> > developers, things which where legal in the past become illegal and the other
> > way around, whats the current gcc implementation or the oppinion of the gcc
> > developers simply is not that usefull, you cant use it to write code which
> > will work in 5 years, as in 5 years there will be other people working on gcc
> > and they will have another oppinion on what some things mean ...
> 
> So one should not write something that works with past and present versions
> of gcc?  One should instead write something that has been proven to _not_
> work in past and present versions of gcc because you believe that it may
> become the correct way 5 years from now?

code which violates the respective specification will not be accepted no
matter how you twist the words and you seem to be pretty good at twisting
words

[...]

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