🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.arch
Article #11973

Re: MIPS LL & SC instrs

#11973
From: Charlie Price
Date: Fri, 07 Jun 1991 04:52
92 lines
4571 bytes
In article <24990@samsung.samsung.com> reinhard@tristar.samsung.com (Steven Reinhardt) writes:
>Some examples were given for MIPS systems using LL and SC
>instructions (load-linked and store-conditionally, I believe).
>I'd never heard of these, but I assumed that they had been
>added post-R3000 for MP synchronization.  Would someone be
>kind enough to post a description of their semantics?

Since mash is out of town...

The semantics are pretty simple.
Load Linked loads a word from memory into a register.
A subsequent Store Conditional to that location will
succeed (store the word and return a success indication)
if the location has not been changed in the interim
and will fail (memory unchanged, failure returned) otherwise.
These are user-mode instructions for MIPS-2 architectures:
the R6000 and
the presumably-to-be-announced-as-a-product-someday-soon R4000.

Details:

   6        5         5           16            field size
_____________________________________________
| LL  | base-reg | tgt-reg |     offset     |
---------------------------------------------
_____________________________________________
| SC  | base-reg | src-reg |     offset     |
---------------------------------------------

Both instructions add a 16-bit sign-extended offset
to the value of a base register to formulate the virtual address.

Load Linked loads the addressed word from memory into the target register.

Store Conditional conditionally stores a word from the
src-reg into memory.
The address must be same as that loaded by the last LL.
The store will succeed (modify memory and signal success)
only if the location has not been modified since it was
loaded by the LL.
The store will fail (not modify memory, signal success)
if the location has been modified since the LL.
It will also fail if the processor has changed state
to a less secure level (by executing a return-from-exception).
If the location is forced from cache memory by a cache miss
after the LL instruction, the SC may fail
(LL-stuff-SC sequences should be careful not to cache miss).
Success is indicated by the contents of src-reg after execution
of the instruction:  1 for success and 0 for failure.

For both LL and SC the hardware implements an implicit SYNC:
Loads/stores issued prior to the LL or SC will complete before the
LL or SC touches memory.
Loads/stores issued after the LL or SC will access memory after the
LL or SC touches memory.

For both instructions,
caching (and coherency if supported by the processor)
must be enabled for the virtual address.

Conceptually, the processor watches for changes to the physical
address that was loaded by the LL and knows, for a subsequent SC,
whether it has been modified (written to anyway).
I think the Load Linked name came from the idea of keeping
a "link" between the cached value and memory.
Anything that would "sever" the link would cause a
subsequent SC to fail.
The link can be severed by seeing the location written to
before the SC or by losing track of the address (the
implementation almost certainly requires that it stay
in the processor's cache).
A LL in one context must be protected from an SC in another.
It is sufficient to sever the link whenever the processor
goes to a less-protected state (return-from-exception).

A note on caching and coherence:
For regular addresses on the MIPS processors,
whether the a reference to the address is cached or not
is determined on a per-virtual-page basis by a bit in the
TLB entry.  Your typical user page is cached.
LL/SC only works on locations accessed though the cache.
For processors with cache coherence
(The R6000A used in the R6000-based multiprocessor that CDC
has been talking about and the R4000)
the same thing holds true -- the coherence applied to an access
is a property of the virtual-to-physical translation.
LL/SC only works on locations that are marked coherent
(and therefore kept up to date with memory by hardware).

-- 
Charlie Price    cprice@mips.mips.com        (408) 720-1700
MIPS Computer Systems / 928 Arques Ave.  MS 1-03 / Sunnyvale, CA   94088-3650
Technical Details
Message-ID: <4411@spim.mips.COM>
Path: arc1-ca.pugleaf.net!utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!mips!cprice
References: <24990@samsung.samsung.com>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!mips!cprice
From: cprice@mips.com (Charlie Price)
Newsgroups: comp.arch
Subject: Re: MIPS LL & SC instrs
Message-ID: <4411@spim.mips.COM>
Date: 7 Jun 91 04:52:26 GMT
References: <24990@samsung.samsung.com>
Sender: news@mips.COM
Organization: MIPS Computer Systems, Inc
Lines: 92
Nntp-Posting-Host: lloyd.mips.com