Re: SGI MIPS, Speculative Execution issue

[DiTBho Down in The Bunny hole <downinthebunnyhole%gmail.com@localhost>]

>  A hardware workaround may have been implemented in a later system, or a
> later stepping of the CPU may have the erratum fixed.  Also the crash may
> be unrelated.  You may have to debug it yourself.

Linux never worked on O2/R10K, while, as far as I know, it worked on
IP28 only with patched gcc to force "cache barrier" workarounds.
I cannot find those patches, and I haven't yet understood the issue.

> > I think (my speculation) the hw-mechanism, it implemented, is external
> > to the CPU, but there is more that is not yet clear to me.
>
>  In the R4k and R10k architecture coherency logic is on-chip of all the
> participating agents, both CPU(s) and DMA masters.  See the diagrams in
> the respective processor manuals for an overview.

So, I wonder why IP30 doesn't suffer from this issue ...

I see that Linux, NetBSD and OpenBSD all work fine on IP30, even with
a couple of { R10K, R12K, R14K } CPUs!

The R10K is documented as a four-way superscalar design that
implements register renaming and executes instructions out-of-order.
I wonder if the problem is related to this "out-of-order" nature of
the CPU paired with the Branch Prediction and Speculative Execution
nature of a purist RISC design.

Thinking about that, although one or more instructions may begin
execution during each cycle, and each instruction takes several or
many cycles to complete, when a branch instruction is decoded, its
branch condition may not yet be known. However, the R10000 processor
can predict whether the branch is taken, and then continue decoding
and executing subsequent instructions along the predicted path.

When a branch prediction is wrong, the processor must back up to the
original branch and take the other path. This technique is called
"speculative execution", and whenever the processor discovers a
mispredicted branch, it aborts all speculatively-executed instructions
and restores the processor's state to the state it held before the
branch.

However - the manual says - the cache state is not restored, and this
is clearly a side effect of speculative execution.
Worse still, if the speculative approach involved a Conditional Store
(SC): will it be restored? No, because - the manual says - if the
cache is involved, then it won't be restored, so this is a real mess
that needs at least a sw barrier.

(I can't find software examples, I would like to read them)

I wonder ... is there any hw-mechanism with the IP30 (missing in IP28
and IP32) that saves you when you are playing with cached-memory and
or LL/SC instructions in a conditional block (e.g. semaphore, mutex,
etc)?

if this is *THE* problem.