3 ms·
All RISC-V CPUs seem to be in-order right now, but I assume their ISA supports speculative execution for out-of-order CPUs. So are they going to redesign that p
by mtgx 9y ago
All RISC-V CPUs seem to be in-order right now, but I assume their ISA supports speculative execution for out-of-order CPUs. So are they going to redesign that part of the ISA in a future update, before companies start coming out with out-of-order RISC-V CPUs with speculative execution? I assume some of them were already mid-design of their out-of-order chips, so this could delay their launches quite a bit. But it would be for the best long-term.
- huntie 9y agoNot sure if they've done a production run, but BOOM[1] has existed for a while. I'm not sure if it supporst speculative execution yet. [1] https://github.com/ucb-bar/riscv-boom https://github.com/ucb-bar/riscv-boom
- _chris_ 9y agoIt's been taped out as a research chip, but no production runs. Naturally, like any OOO-issue processor, it supports speculative issuance of load operations to the memory system (or it wouldn't be worth the effort of OOO-issue).
- rwmj 9y agoWhat needs to be redesigned? All OOO cores should behave as if they are executing in order when viewed by the programmer.
- poizan42 9y agoI assume the parent is referring to Spectre.
- nickik 9y agoSeems very unlikely that ISAs will have to change, the problem needs to be fixed in micro Architecture. Its unlikely that there are many mass production RISC-V CPU currently in design. A couple are known but they are more advanced research projects. The BOOM core will be used by Esperanto and I'm sure they will evaluate what to do about the security issues. The guy who made BOOM written about this problems, check on Twitter.
- _chris_ 9y agoSpectre can be completely mitigated, it's just another headache to deal with. =( Essentially, you just have to buffer up more stuff and clear the misspeculated entries so nothing is left lying around that could leak information. Comes with a cost, but chip companies don't have to give up on OOO/speculation entirely.
- CodesInChaos 9y agoSounds tricky. For example if your CPU has hyperthreading, cache misses in speculative execution could leak to the other thread running on the same core, because they share computational resources and the utilization of those is affected by cache misses in speculative execution.
- _chris_ 9y agoYou tag things and prevent bypassing uncommitted data from one thread to another. For example, it's a mistake (that's been made by other ISAs!) to allow two hardware threads to bypass store data out of the uncommitted StoreQueue from one thread to another. Your memory consistency model violates single-copy atomicity and now the programmer's life is much harder.
- CodesInChaos 9y agoI'm talking about the shared computation resources (e.g. ALU), not about shared caches. Cache hits and cache misses affect how much and when one thread utilizes the ALU, which means the other thread sharing it won't be able to use the same resources for computation. Since speculative execution also uses these shared resources, it leaks information about its cache misses to the other thread, even if a rolled-back speculative execution doesn't modify any caches.
- monocasa 9y agoRISC-V has a HINT instruction that's a NOP on the cores that don't support it, but can be a microarchitectual hint on the cores that do. One of the encodings for the HINT will almost certainly be a speculative execution barrier.