linux-mips
[Top] [All Lists]

Re: Build failure for R3000 DECstation

To: Ralf Baechle <ralf@oss.sgi.com>
Subject: Re: Build failure for R3000 DECstation
From: Jun Sun <jsun@mvista.com>
Date: Tue, 14 Nov 2000 19:13:08 -0800
Cc: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>, Harald Koerfgen <Harald.Koerfgen@home.ivm.de>, linux-mips@oss.sgi.com
References: <20001115004122.G927@bacchus.dhis.org> <Pine.GSO.3.96.1001115014410.11897A-100000@delta.ds2.pg.gda.pl> <20001115024358.A3182@bacchus.dhis.org>
Sender: owner-linux-mips@oss.sgi.com
Ralf Baechle wrote:
> 
> On Wed, Nov 15, 2000 at 01:58:21AM +0100, Maciej W. Rozycki wrote:
> 
> > > In any case, for uniprocessor non-ll/sc machines there is also a better
> > > solution availble with no syscalls at all.  It's easy to implement, just
> > > use the fact that any exception will change the values of k0/k1.  That of
> > > course breaks silently on SMP.
> >
> >  Can you guarantee it???  Well I can guarantee k0 and k1 won't change when
> > least expected. ;-)  AFAIK, the only fact guaranteed is that exception
> > handlers do not preserve the values of the scratch registers, but it does
> > not mean the last value written there is always different from what was
> > there upon a handler's entry...
> 
> Make that change k0 to a non-zero value.  So a R3000 UP spinlock can look
> like:
> 
>         move    k0, zero
>         li      t0, 1
> 0:      sw      t0, spin
>         bnez    k0, 0b
> 
>         [critical section]
> 
>         sw      zero, spin
> 
>   Ralf
> 
> (Who should write thousant times ``I shall not post with a phone in my hand'')

You should not post when you are sleepy. :-)

The above code does not work - the loop is infinite as nobody will set
k0 to 0 again if it is not zero for the first time.

In fact, I don't think you can perform automic operation ONLY based on
the knowledge whether a context switch has happened during a specified
period.  (It should be interesting to see if we can actually "prove"
it.)

I also doubt if k0 is absolutely non-zero after a context ...

Jun

<Prev in Thread] Current Thread [Next in Thread>