From: Hartvig Ekner <hartvige@mips.com>
To: macro@ds2.pg.gda.pl (Maciej W. Rozycki)
Cc: ralf@oss.sgi.com (Ralf Baechle),
hartvige@mips.com (Hartvig Ekner),
justinca@ri.cmu.edu (Justin Carlson),
dan@debian.org (Daniel Jacobowitz), hjl@lucon.org (H . J . Lu),
dom@algor.co.uk (Dominic Sweetman),
libc-alpha@sources.redhat.com (GNU C Library),
linux-mips@oss.sgi.com
Subject: Re: PATCH: Fix ll/sc for mips (take 3)
Date: Tue, 5 Feb 2002 13:38:34 +0100 (MET) [thread overview]
Message-ID: <200202051238.NAA03846@copsun18.mips.com> (raw)
In-Reply-To: <Pine.GSO.3.96.1020205131750.9674E-100000@delta.ds2.pg.gda.pl> from "Maciej W. Rozycki" at Feb 05, 2002 01:31:05 PM
Some of MIPS's cores do externalize the event of a "LL" and make it
visible on the bus interface. Similarly, the SC is externalized and
requires a go/nogo response from the system logic. Think of it as
putting a shared LLAddr & LLBit outside the processor. The SC will
only succeed if the internal LLBit is ok *and* the external logic gives
the go-ahead as well.
The reasoning behind all this is that one can then utilize LL/SC in
multi CPU systems without full coherency support being required.
But then again, this might not be relevant for MIPS/Linux as it will not
run without full HW coherency on multiple CPUs?
/Hartvig
Maciej W. Rozycki writes:
>
> 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 +
>
>
--
_ _ _____ ____ Hartvig Ekner Mailto:hartvige@mips.com
|\ /| | |____)(____ Direct: +45 4486 5503
| \/ | | | _____) MIPS Denmark Switch: +45 4486 5555
T E C H N O L O G I E S http://www.mips.com Fax...: +45 4486 5556
WARNING: multiple messages have this Message-ID (diff)
From: Hartvig Ekner <hartvige@mips.com>
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc: Ralf Baechle <ralf@oss.sgi.com>,
Hartvig Ekner <hartvige@mips.com>,
Justin Carlson <justinca@ri.cmu.edu>,
Daniel Jacobowitz <dan@debian.org>, "H . J . Lu" <hjl@lucon.org>,
Dominic Sweetman <dom@algor.co.uk>,
GNU C Library <libc-alpha@sources.redhat.com>,
linux-mips@oss.sgi.com
Subject: Re: PATCH: Fix ll/sc for mips (take 3)
Date: Tue, 5 Feb 2002 13:38:34 +0100 (MET) [thread overview]
Message-ID: <200202051238.NAA03846@copsun18.mips.com> (raw)
Message-ID: <20020205123834.MuRIHydPU3cCfBh2tIfcYD-qKSCvpPRA29ieBmcBRwc@z> (raw)
In-Reply-To: <Pine.GSO.3.96.1020205131750.9674E-100000@delta.ds2.pg.gda.pl> from "Maciej W. Rozycki" at Feb 05, 2002 01:31:05 PM
Some of MIPS's cores do externalize the event of a "LL" and make it
visible on the bus interface. Similarly, the SC is externalized and
requires a go/nogo response from the system logic. Think of it as
putting a shared LLAddr & LLBit outside the processor. The SC will
only succeed if the internal LLBit is ok *and* the external logic gives
the go-ahead as well.
The reasoning behind all this is that one can then utilize LL/SC in
multi CPU systems without full coherency support being required.
But then again, this might not be relevant for MIPS/Linux as it will not
run without full HW coherency on multiple CPUs?
/Hartvig
Maciej W. Rozycki writes:
>
> 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 +
>
>
--
_ _ _____ ____ Hartvig Ekner Mailto:hartvige@mips.com
|\ /| | |____)(____ Direct: +45 4486 5503
| \/ | | | _____) MIPS Denmark Switch: +45 4486 5555
T E C H N O L O G I E S http://www.mips.com Fax...: +45 4486 5556
next prev parent reply other threads:[~2002-02-05 12:38 UTC|newest]
Thread overview: 75+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-01-31 20:35 PATCH: Fix ll/sc for mips H . J . Lu
2002-01-31 22:17 ` Maciej W. Rozycki
2002-01-31 22:41 ` H . J . Lu
2002-02-01 3:35 ` Hiroyuki Machida
2002-02-01 4:02 ` [libc-alpha] " Kaz Kylheku
2002-02-01 4:02 ` Kaz Kylheku
2002-02-01 4:59 ` Hiroyuki Machida
2002-02-01 7:00 ` H . J . Lu
2002-02-01 11:12 ` Hiroyuki Machida
2002-02-01 10:49 ` Andreas Schwab
2002-02-01 11:23 ` Geoff Keating
2002-02-01 7:10 ` H . J . Lu
2002-02-01 7:17 ` H . J . Lu
2002-02-01 11:45 ` Maciej W. Rozycki
2002-02-01 18:29 ` PATCH: Fix ll/sc for mips (take 3) H . J . Lu
2002-02-01 23:01 ` Daniel Jacobowitz
2002-02-01 23:15 ` H . J . Lu
2002-02-02 2:37 ` Hiroyuki Machida
2002-02-04 9:32 ` Dominic Sweetman
2002-02-05 6:16 ` Jay Carlson
2002-02-05 8:28 ` Ralf Baechle
2002-02-05 15:10 ` Jay Carlson
2002-02-05 16:06 ` Jay Carlson
2002-02-02 3:26 ` Daniel Jacobowitz
2002-02-02 18:53 ` Justin Carlson
2002-02-02 20:03 ` H . J . Lu
2002-02-02 20:49 ` Hartvig Ekner
2002-02-02 20:49 ` Hartvig Ekner
2002-02-03 5:47 ` Justin Carlson
2002-02-04 19:17 ` Paul Koning
[not found] ` <mailpost.1012680250.7159@news-sj1-1>
2002-02-03 23:29 ` cgd
2002-02-04 6:07 ` Ralf Baechle
2002-02-04 9:46 ` Dominic Sweetman
2002-02-04 16:31 ` H . J . Lu
2002-02-04 16:46 ` Dominic Sweetman
2002-02-05 1:28 ` H . J . Lu
2002-02-05 2:58 ` Daniel Jacobowitz
2002-02-05 4:42 ` H . J . Lu
2002-02-05 4:47 ` Daniel Jacobowitz
2002-02-05 5:30 ` Justin Carlson
2002-02-05 8:39 ` Hartvig Ekner
2002-02-05 8:39 ` Hartvig Ekner
2002-02-05 11:37 ` Maciej W. Rozycki
2002-02-05 12:12 ` Ralf Baechle
2002-02-05 12:31 ` Maciej W. Rozycki
2002-02-05 12:38 ` Hartvig Ekner [this message]
2002-02-05 12:38 ` Hartvig Ekner
2002-02-05 13:28 ` Maciej W. Rozycki
2002-02-05 19:28 ` Hartvig Ekner
2002-02-05 19:28 ` Hartvig Ekner
2002-02-05 18:59 ` Ralf Baechle
2002-02-05 19:30 ` H . J . Lu
2002-02-05 21:54 ` H . J . Lu
2002-02-06 10:32 ` Ralf Baechle
2002-02-06 20:45 ` Why does -g turn off filling the delat slot? H . J . Lu
2002-02-06 21:00 ` PATCH: Modify the mips gas behavior for -g -O H . J . Lu
2002-02-06 21:16 ` Eric Christopher
2002-02-06 21:40 ` Ian Lance Taylor
2002-02-06 21:46 ` Eric Christopher
2002-02-06 22:00 ` PATCH: Define SUBTARGET_ASM_DEBUGGING_SPEC for Linux/mips H . J . Lu
2002-02-07 8:24 ` Eric Christopher
2002-02-06 11:37 ` PATCH: Fix ll/sc for mips (take 3) Maciej W. Rozycki
2002-02-04 17:44 ` cgd
2002-02-04 6:46 ` Ralf Baechle
2002-02-04 7:01 ` PATCH: Fix ll/sc for mips Ralf Baechle
2002-02-04 14:54 ` Maciej W. Rozycki
2002-02-01 11:50 ` Maciej W. Rozycki
2002-02-01 17:40 ` H . J . Lu
2002-02-01 21:41 ` Maciej W. Rozycki
2002-02-01 22:47 ` H . J . Lu
2002-02-02 11:06 ` Maciej W. Rozycki
2002-02-03 2:29 ` Ulrich Drepper
2002-02-03 2:29 ` Ulrich Drepper
2002-01-31 23:33 ` [libc-alpha] " Kaz Kylheku
2002-01-31 23:33 ` Kaz Kylheku
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200202051238.NAA03846@copsun18.mips.com \
--to=hartvige@mips.com \
--cc=dan@debian.org \
--cc=dom@algor.co.uk \
--cc=hjl@lucon.org \
--cc=justinca@ri.cmu.edu \
--cc=libc-alpha@sources.redhat.com \
--cc=linux-mips@oss.sgi.com \
--cc=macro@ds2.pg.gda.pl \
--cc=ralf@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox