From Newsgroup: comp.arch
On 6/5/2026 6:44 PM, MitchAlsup wrote:
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> posted:
On 6/5/2026 7:02 AM, Michael S wrote:
On Thu, 4 Jun 2026 18:28:43 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wrote:
On 6/4/2026 7:21 AM, Scott Lurndal wrote:
Andy Valencia <vandys@vsta.org> writes:
I do not think it is impossible for an architecture to make
guarantees about LL/SC operations.
I was at Sequent when we were really serious about moving off Intel >>>>>> onto MIPS. We looked at LL/SC really, really hard. Lock traces
from current systems, SW simulations, down to gate-level
simulations.
We ended up being sufficiently confident (as in, bet the program,
by implication bet the company) that it would work as efficiently
as our current Intel atomics at up to 8-way 64-bit MIPS CPU's. And >>>>>> that it was very likely to scale without undue incremental design
work to ~32 CPU's.
I was at Unisys in that same timeframe; we had planned on building
the SPP (scalable parallel processor aka OPUS) using motorola 88110
CPUs, until Apple went PPC and Moto canceled 88110. So we
investigated MIPS, SPARC and Pentium Pro. Our target was for a 64+
processor SPP. After evaluation, we chose Pentium Pro to build the
system (using the Intel Paragon backplane).
I don't recall the details of the MIPS evaluation, but we were
concerned at the time about the scalability of LL/SC. SPARC never
made it out of the first evaluation round.
Why? I had a SunFire T2000 that, when programmed correctly, was
pretty fast for certain worksets and algorithms. RMO mode.
RMO mode?
I am pretty sure that T2000 had no RMO mode.
If I am not mistaken, the only Sun SPARC CPUs that had RMO in hardware
were UrtraSPARC and UrtraSPARC II.
Oh shit, I think you are right! I sometimes get my old SPARC boxes mixed up. >>
Iirc, UltraSPARC T1 was a full SPARC V9 implementation, and SPARC V9
defines three memory models: TSO, PSO, and RMO.
It still needed an explicit membar for a store followed by a load to
another location, even in TSO.
Actually, I forgot how I go some sparcs in RMO mode. PSTATE?
Starting from UrtraSPARC III Cu, all Sun SPARC processors are documented >>> to be TSO-only. The processor, for which I didn't find a definite
statement is an original UrtraSPARC III (Chitah), but I would be very
surprised if it is not the same as UrtraSPARC III Cu.
SPARC-T line (originaaly named Niagara) was TSO-only from the very
start.
The only remnant of RMO in these processors are Block load and store
operations operations - they behave as RMO regardles of processor's
global memory mode.
Remember that old thing in one of the SPARC docs that explicitly
mentioned to NEVER put a MEMBAR instruction in the branch delay slot?
SPARC used nullification in delay slots.
Iirc, might be wrong here, a MEMBAR can force processor serialization or
stall the pipeline until the store buffers drain, executing it right
when the processor is updating the PC and nPC for a branch created nasty timing hazards? God its been a long time since I read the docs...
--- Synchronet 3.22a-Linux NewsLink 1.2