Hacker News new | ask | show | jobs
by Symmetry 1395 days ago
The flexibility that makes RISC-V so compelling in embedded roles (what if I want 64 bit address but don't need hardware floating point?) makes it a harder target for the sort of workloads that you'd usually run on a server or desktop. If I were going to create an open high performance core to challenge x86 and ARM's A series cores I'd probably use PowerPC as a base rather than RISC-V. But I do think that RISC-V has a bright future in other segments.
2 comments

RISC-V is very flexible, yes, but most 'desktop-class'/application processors are expected to implement at least RV64GC. G is short for IMAFD, so mul/div, atomics, and floating point are all in there, as well as compressed instructions (C) to reduce code size.

Other features you're likely to want are also included in the specification, so if you want to write code that uses for example the B bit manipulation extension or the V vector extension (which is scalable with vector width as well, unlike SSE/AVX) you just have to check a standardized 'CPUID' bit and can run your code, and otherwise fall back to other code.

I also believe that the spec may let operating systems hook these instructions and provide fallbacks so application developers don't have to, but I'm not too sure on the specifics of the privileged ISA of RISC-V.

What are the trade-offs of PowerPC vs RISC-V?
In addition to RISC-V being more flexible than ideal here, PowerPC is more complicated as an instruction set which is a drawback if you're a student learning to implement your first processor or in a deeply embedded role. But given the huge amount of effort that goes into a high performance core it gets lost in the noise and it lets you execute tasks in fewer instructions without crazy difficult to implement levels of instruction fusion.
RISC-V does not in any way depend on instruction fusion. I don't why this meme persists, especially as no RISC-V cores in the market do instruction fusion.

High end OoO cores in other ISAs are BREAKING DOWN complex instructions into µops. RISC-V is pre-broken down. The one exception to that is current x86 and ARM cores DO do instruction fusion, to combine a compare with a following conditional branch. Which is a singe instruction in RISC-V in the first place. SO it is actually the other way around.

Low end cores shouldn't be doing either fusion or breaking down into µops. They are supposed to be as simple as possible, and doing either of those is a complication using significant silicon area and energy.

There might be a place for instruction fusion in mid-range cores. Things in the ARM Cortex A53 / A55 / A510 range. The most popular RISC-V core in that segment, the SiFive U74 (used in the HiFive Unmatched, BeagleV Starlight, VisionFive v1, VisionFive 2, Pine64 Star64 .. and probably more yet to be announced) doesn't fuse multiple instructions into one instruction, but it does pair a forward conditional branch past a single instruction with that following instruction. Both instructions still exist, they each go down one of the two execution pipelines side by side, the same as if the branch was predicted not-taken. At the final pipe stage if the branch turns out to be taken, instead of taking a mis-predicted branch penalty and flushing the pipeline, the U74 simply does not write the result of that following instruction back to the destination register.

That's the closest any currently shipping RISC-V core I know of comes to instruction fusion.

"crazy difficult to implement levels of instruction fusion" does not exist anywhere, and is not needed. It's just an idea from an academic which doesn't actually exist in the real world, at least at present.

The meme persists because the ISA has a lot of “simple” instructions that don’t actually match what real world software would like to make performant, so a bunch of RISC-V enthusiasts handwave it away as “oh the chip will just fuse all the instructions and make it efficient”.