I've been slowly working through the Stephen Mraz "Build a RISC-V OS In Rust" project to familiarize myself with RISC-V and it's been a pretty enlightening experience.
One issue that I've run into though, which is also noticeable in this article, is that a lot of things like ISA extensions are specified in either repos that don't show a diff vs the main spec, or are just inline in the massive PDF. What's the point of linking specifically to the "Ztso" extension if it's just going to download the main ISA specification.
Wasm faces a similar issue, with lots of fork repos for extensions that don't at all outline how the extension operates or changes the core.
It makes me long for "HTML (single page)" in the GNU tradition.
Yes, linking to specific specifications can be a pain once they've been added to the main ISA doc. Perhaps I'd be better off linking to the raw .tex, but that's not always particularly readable or as I think you suggest, not bother linking at all if the link isn't directly to the mentioned extension.
> The ISA spec includes commentary on this decision (page 23), noting some disadvantages of adding such instructions to the specification and noting microarchitectural techniques exist to convert short forward branches into predicated code internally. In the case of the SiFive 7 series, this is achieved using macro-op fusion where a branch over a single ALU instruction is fused and executed as a single conditional instruction.
i wonder how far can macro-op fusion be taken?
would it be possible to implement something like push/pop all registers where the hardware decoder gobbles up several consecutive load (or store) instructions and executes an (accelerated) batch under the covers?
(maybe thats a trick they already do i suppose....)
It probably already does that. It probably goes even further.
Intel CPUs since the Core uarch have a stack engine. This basically does the addition or subtraction of the stack pointer in a special piece of hardware straight after the decode stage. It can also do this multiple times per clock. The result after decode is that each PUSH/POP/PUSHQ/POPQ will decode down to a single uop. Combined with multiple decoding pipes and a superscaler load/store unit the CPU basically packs a stream of PUSH(Q)/POP(Q) instructions into a tight little ball of uops which are executed at lightning speed. On Alder Lake for instance it can do 3 loads and 4 stores per clock.
This is also faster than putting an instruction like PUSHA/POPA through a uarch decoder so nobody uses those instructions anymore. They're not even available in the x64 ISA. As shown, modern CPUs are so good at decoding a stream of individual PUSH(Q)/POP(Q) instructions there's literally no point.
What does it mean for LLVM to support Zawrs? The feature is similar to x86 UMWAIT. To exploit UMWAIT I have to insert assembly code. Are there higher-level language constructs that can trigger these features? If not, what does LLVM support mean? Only that the compiler backend can see the instruction without freaking out?
Yes, just that it will assemble the instructions. I was double checking as I was sure I'd qualified this when appropriate with "assembler/disassembler" but it seems I didn't - apologies. I'll tweak the wording to make this clearer. (EDIT: fixed).
Sadly I have to agree that China is definitely the reason we see so much activity in the RISC-V space. That said I hope an open ISA will lead to harder competition and better processors than we see with closed ones. But it's obviously a push to create all-Chinese market-leading processors.
It’s exactly what will happen. This is a zero sum game. Hardware is not like software where open source can just easily be used by everyone. Hardware is expensive and takes years to develop and iterate. Yes RISC-V is fun for various research projects, but the reality is any serious chip will have extreme requirements to be successful. One of them is complete software support (binaries, OSes, compilers, debuggers, JIT engines, etc). If you enable that, you enable a serious hardware company. China is missing the software bit to entice adoption of its chips. It’s a winner-takes-all situation, and they publicly talk about their intention to take over. Few outside of China win in that situation.
One issue that I've run into though, which is also noticeable in this article, is that a lot of things like ISA extensions are specified in either repos that don't show a diff vs the main spec, or are just inline in the massive PDF. What's the point of linking specifically to the "Ztso" extension if it's just going to download the main ISA specification.
Wasm faces a similar issue, with lots of fork repos for extensions that don't at all outline how the extension operates or changes the core.
It makes me long for "HTML (single page)" in the GNU tradition.
would it be possible to implement something like push/pop all registers where the hardware decoder gobbles up several consecutive load (or store) instructions and executes an (accelerated) batch under the covers?
(maybe thats a trick they already do i suppose....)
Intel CPUs since the Core uarch have a stack engine. This basically does the addition or subtraction of the stack pointer in a special piece of hardware straight after the decode stage. It can also do this multiple times per clock. The result after decode is that each PUSH/POP/PUSHQ/POPQ will decode down to a single uop. Combined with multiple decoding pipes and a superscaler load/store unit the CPU basically packs a stream of PUSH(Q)/POP(Q) instructions into a tight little ball of uops which are executed at lightning speed. On Alder Lake for instance it can do 3 loads and 4 stores per clock.
This is also faster than putting an instruction like PUSHA/POPA through a uarch decoder so nobody uses those instructions anymore. They're not even available in the x64 ISA. As shown, modern CPUs are so good at decoding a stream of individual PUSH(Q)/POP(Q) instructions there's literally no point.
Thanks to this, we can truly have an open, high-quality, industry-standard ISA for everyone.
Talk about a distorted view of the world. These toolchains are packed full of eastern contributions.