I've already written the paper and it's just got to survive a lot of peer review. It turns out that it would be real easy to envisage an in-order processor that has some mechanism for speculation that was actually vulnerable to spectre and variations of meltdown and the paper explores that - so hopefully it's an interesting paper even if the tl;dr is we claim to be immune.
if (index < bounds) {
index2 = array1[index];
... array2[index2];
}
You could obviously fix this by never generating code that does double speculation, but you could also do that by modifying a conventional OoO microarchitecture.
This variant of Spectre would be software bug not a hardware bug on the mill.
Our specialiser had to be fixed to not produce code with this flaw.
And so we wrote a light paper on it, and perhaps a talk etc ;)
Since turf permissions operate on the granularity of an arbitrary address range (rather than a page like traditional MMUs), the permissions cache (what the Mill calls a PLB) has a worse latency/power tradeoff than a traditional TLB. The Mill takes advantage of its single address space and reduces some of this hit by doing permissions checks in parallel with the access.
[1] https://millcomputing.com/docs/metadata/ [2] https://millcomputing.com/docs/inter-process-communication/
Luckily its not quite as you interpreted:
The L1$D is accessed in parallel with the PLB. Both at top-level caches - one for data, one for protection.
If there is a PLB miss we have no cache-visible side-effects until the protection has been resolved.
The paper we're preparing will cover this in detail, because as you can see, the talks are a bit light on exactly what happens in what order when here.
Isn't prefetching/load-hoisting pretty much required to get any sort of performance out of an in-order VLIW-like machine?