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

Michael Niedermayer michaelni at gmx.at
Thu Nov 2 03:08:41 CET 2006


Hi

On Wed, Nov 01, 2006 at 11:47:22AM -0800, Trent Piepho wrote:
> On Wed, 1 Nov 2006, Michael Niedermayer wrote:
> > On Wed, Nov 01, 2006 at 03:42:30AM -0800, Trent Piepho wrote:
> > > On Wed, 1 Nov 2006, Michael Niedermayer wrote:
> > > > On Tue, Oct 31, 2006 at 01:13:29PM -0800, Trent Piepho wrote:
> > > > does gcc 2.7.2 compile mplayer at all?
> > >
> > > Sorry, I meant 2.95, but I'm not sure if that's the case.  Some older gcc
> 
> I'm now more sure of how this worked.  In 2.7.2, '+' wasn't allowed.  In
> 2.95, it was allowed but didn't work correctly.  I'm not sure when, or if,
> it was fixed.

well fact be mplayer uses "+" frequently and mplayer works very well with 
2.95.3+, there where some big bugs in 2.95.2 related to asm though i dunno
if they where related to "+"


> 
> > > You might also want to look at these threads:
> > > http://marc.theaimsgroup.com/?l=linux-kernel&m=107475162200773&w=2
> 
> > > > does not prevent %0 == %1 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 "=&..."
> > > > iam not sure if that could cause any problems with your code as i didnt look
> > > > at it, just the constraints quoted above in which "=m" (accumulator) and
> > > > "m" (accumulator) could be in the same memory location or a different one
> > > > or "=m" (accumulator) and "g" (stride) could be in the same memory location
> > >
> > > How could accumulator be in two different memory locations?
> >
> > an opimizing compiler can make a copy, for example it could copy it to
> > the stack, gcc may or may not be capable of that but that doesnt matter
> > for the validity of the code ...
> 
> It isn't allowed do that. 

wrong, a optimizing c compiler is allowed to do anything which doesnt
violate the c standard


> If it did, it would be impossible to write
> atomic operations. 

it is impossible in C with the exception of read and write of 
volatile sig_atomic_t


> There would be no way to write something like a
> spin-lock.

iam no spinlock expert but i think you cannot write a spinlock in pure
iso/ansi C, you need asm for that and thats then no longer related to
what a c complier can or cannot do

and if you define your own (asm) standard then you are also free to
define that volatile or some specific other syntactical element prevents
some optimization


> 
> > > Before you say gcc could allot some new memory and copy the variables in
> > > and out, please read the message from Richard Henderson that I linked to
> > > that explains why this can't be done.
> >
> > yes i read it, i also read linus reply which basically said
> > "Please fix the compiler"
> 
> Linus is saying allow "+m"(x) constraints by making them the same as
> "=m"(x):"m"(x).

... with the additional comment "since you say it is equivalent anyway."

which ive no problem with either, but please dont twist the facts,
fact seems to be gcc due to limitations of its architecture cannot
copy or move a variable to another memory locations, and with this
additional limitation of the current gcc implementation
"=m"(a), "0"(a) is equivalent to "=m"(a), "m"(a)
this is NOT guranteed by the gcc docs and neither is it gurateed to
work in the future, so it MUST NOT be used in code, OTOH gcc as long
as it has this limitation can change "=m"(a), "0"(a) and "+m"(a) to
"=m"(a), "m"(a) if that has any benefit for it

also iam not entirely sure but gcc-svn did break our code once
due to missing "memory" on the clobber list and even though iam not
completely sure why that happened, the most obvious reason why it failed
would be that gcc did copy a variable onto the stack and used it from
there (it could not have had a copy in a register as my asm code used
all for other stuff)


>  He's not saying gcc should be able to copy variables in
> and out of a temporary memory location for asm constructs.  In fact, he
> specificly says something like "=m"(x) :  "0"(y) that would require two
> different variables to be in the same place in memory shouldn't be allowed.

in the thread you linked linus just agrees that the meaning of 
"=m"(x) :  "0"(y) is unclear
not that it matters that much what he says, but its just not what
you claim ...

[...]

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



More information about the MPlayer-dev-eng mailing list