I think this narrative is false. CPU vendors pushed increased speeds to sell more cpus. Demand was a function of supply. There was no need for more speed until sw vendors started writing (super-bloated shit code) to higher-end systems they could assume users had.
Absolutely. Any approach that requires work by the programmer or compiler is fundamentally bogus.
-
-
If compiler can do it, why is it bogus? We require compilers to allocate registers.
-
Because that's a fundamental change to the ISA tgat renders existing software unsupported. A new ISA could require it, of course, but that seems dangerous & error-prone.
-
Why is that "dangerous and error-prone"? Lots of CPUs only have one trust boundary. Why do we need to make fix only hardware?
-
Because people sometimes write asm by hand & are likely to get it wrong. But nobody's making a new ISA right now anyway. RV is already spec'd & in use.
-
You can add speculation barriers where they are needed.
-
Again, adding them to an existing ISA is pointless because you're not fixing the bug - that you broke the original ISA contract.
-
We've got an actual security issue: it doesn't matter whether we change the ISA contact+modify software to fix. What matters is it gets fixed. And lots of machines won't have this issue.
-
Yes it does matter. You really have no idea what you're talking about.
- 4 more replies
New conversation -
-
-
I was talking about having the cpu do what you're calling a "speculation barrier" though not introducing it as a programming model.
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.