This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: PATCH: Fix ll/sc for mips (take 3)
- From: "Maciej W. Rozycki" <macro at ds2 dot pg dot gda dot pl>
- To: Ralf Baechle <ralf at oss dot sgi dot com>
- Cc: Hartvig Ekner <hartvige at mips dot com>, Justin Carlson <justinca at ri dot cmu dot edu>, Daniel Jacobowitz <dan at debian dot org>, "H . J . Lu" <hjl at lucon dot org>, Dominic Sweetman <dom at algor dot co dot uk>, GNU C Library <libc-alpha at sources dot redhat dot com>, linux-mips at oss dot sgi dot com
- Date: Tue, 5 Feb 2002 13:31:05 +0100 (MET)
- Subject: Re: PATCH: Fix ll/sc for mips (take 3)
- Organization: Technical University of Gdansk
On Tue, 5 Feb 2002, Ralf Baechle wrote:
> Some of the processor manuals explicitly note that the execution of a
> ll instruction may not be visible at all externally. That's the case if
> the address is already in a primary cache line in exclusive (ll) or
> dirty (sc) state. That makes even if a processor supports full coherency
> since there is no reason to indicate the update to any other external
> agent. Or am I missing something?
By definition, apart from an ordinary load, an "ll" does only the
following two additional actions:
1. Loads the LLAddr register (it's visible in CP0, at least in certain
implementations) to set up the ll comparator.
2. Sets the LLbit flip-flop to set the ll state to valid initially.
None of the actions should normally involve externally visible activity.
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: macro@ds2.pg.gda.pl, PGP key available +