RISC-V open architecture allows designers to implement their own instructions, and some of those may become an official RISC-V extension. But the process to approve a new extension may have been suboptimal, so RISC-V International has just unveiled the Fast Track Architecture Extension Process, or Fast Track for short, that streamlines the ratification of small architecture extensions, as well as ZiHintPause, the first extension to be ratified under the new Fast Track process.
The process is designed for simpler extensions that are uncontentious and offer value to the RISC-V community at large, so it’s not suitable for more complex extensions. An extension that has been submitted for consideration will undergo an internal review before entering a 45-day public review process. You can read detailed rules for the new extension ratified process here.
The ZiHintPause extension went through this 45-day review process on Google Group, and was very recently ratified. The ZiHintPause extension is meant to reduce the energy consumption of designs, improve the performance of spin-wait loops, enable multithreaded cores to temporarily relinquish extension resources. The extension is really simple as it adds a single PAUSE instruction (encoded as a HINT instruction) to the RISC-V ISA.
We asked RISC-V International about a specific real-life use case showing the improved power consumption with the PAUSE instruction, but the organization was unable to provide this type of information at this time. For more details, you can read the one! page “Zihintpause” Pause Hint, Version 1.0 document describing the instructions.
Jean-Luc started CNX Software in 2010 as a part-time endeavor, before quitting his job as a software engineering manager, and starting to write daily news, and reviews full time later in 2011.
Support CNX Software! Donate via cryptocurrencies, become a Patron on Patreon, or purchase goods on Amazon or Aliexpress
Oh very likely it’s like for other architectures where it allows a core/thread to do nothing for a few tens of cycles. This is useful inside locks: instead of hammering the cache line trying to grab the lock again, you leave more memory bandwidth to the other core to let it finish what it started. In addition to finishing faster, it usually consumes less power while waiting. The difference is impressive in SMT where it can almost double the performance by not having the CPU pipelines spend half of their capacity executing useless instructions.
How does this fast track process compare to the challenges the eoma68 guy faced in getting his vector extensions accepted for his hybrid GPU?
IIRC, he was rejected by RISC-V and found IBM’s openpower group more accommodating.
I think you missed a couple of words there: *small” architecture extensions, and “uncontentious”.
First lkcl’s proposed extension used not just a single instruction encoding, but a vast amount of 32 bit instruction encoding space — IIRC, more than the official RISC-V Vector extension — and *all* of the 48 bit opcode space.
Second, a “PAUSE” instruction is something well known in the industry. Other architectures have it already and it provides clear benefits. It is uncontentious. It is even backward compatible in that new programs using it will run fine on older CPUs that don’t know about it because it uses an otherwise useless (no-op) encoding within the existing FENCE instruction.
In contrast lkcl’s vector extension was a completely untried technology that might not even work, and if it worked might give no advantage worth its cost. He should implement it as a custom extension, show that it works and is useful, get other people interested in also implementing it AND THEN propose it as a standard extension.
p.s. how long have I been waiting for my eoma68 “Practically Perfect Computer Card” now?
The article says it’s encoded as a “HINT” instruction. You said it’s in an effectively NOP encoding of the FENCE instruction. That seems to be a contradiction. Could you explain it in more detail for those of us unfamiliar with the situation? Thank you.
David, it’s not contradictory. You can have instructions that have no effect on previous models and that have a bit of effect on new ones. Look at the REP NOP on x86 which does a pause for example. Similarly there used to be hints for branches (likely/unlikely) by using cs: or ds: segment prefixes before jumps. All of these have zero effect on other CPUs but on those which can use them they are useful.
I’m just looking for clarification on which OPCODE this is using previously “effectively NOP” versions of. I understand how that works in instruction coding. Moves with the source and destion being the same, AND/OR of an operator with itself, etc. There are plenty of them when you have orthogonal instruction codings.
What I’m unclear of is there an OPCODE for “HINT” and one for “FENCE” and how this new instruction can be part of both of them. Is one already a part of the other?
Ah OK got it 🙂 For this one I don’t know!
Looks like Bruce isn’t going to respond. ;(