Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I'm missing the reason why RISC-V in particular is (claimed to be) so much better suited for building specialized co-processors. Are they talking about ISA extensions? Or maybe that the royalty free model makes it cheaper?


Maybe you skipped the section "What is the benefit of sticking with Risc-V"?

> But for a coprocessor you don’t want or need this large instruction-set. You want an eco-system of tools that have been built around the idea of a minimal fixed base instruction-set with extensions.

Essentially: the modular nature of Risc-V and tooling/ecosystem built around it, with first class extension support.

ARM is closed, too complex and not friendly to extensions, while custom ISAs mandate a huge amount of extra work.

I only dabble in this field, but I see the ecosystem rapidly maturing. The open nature also leads to a general propensity to open source designs and tooling, lowering the barrier to entry and reducing cost.


I think people think it's going to be a vibrant open ecosystem in collaboration with industry and academia with a lot of development and fresh ideas leading to some significant simplification and so opportunity for performance and functionality breakthroughs. I don't know if that's true or not.


Same, I love the idea of RISC-V but I don’t really get how it’s better either from a technical standpoint. Would love to hear more about the main advantage of RISC-V against others.


I implement RISC-V for a living and for fun. Arm64 is a very good modern ISA. RISC-V is good too. Comparison with RISC-V must account for the much broader purpose of RISC-V, but just to focus on a few points (I'm not an Arm64 expert though):

* RISC-V (RV64GC) have simpler instructions than Arm64. It's possible it would have a slight frequency advantage given the same implementation resources, but Arm64 might need slight fewer instructions. Notably, Arm64 have more addressing modes. Fusion and cracking makes this mostly a wash, but implementing a RV64 cores is a lot easier than an Arm64 (I speculate).

* Arm64 has load pairs and store pairs; this is a significant advantage.

* RISC-V has no flags and conditional branches directly compares operands. This look like a significant advantage in the code I have looked at and is easier to implement (no flag renaming etc.)


   load pairs and store pairs;
What is the advantage of Load/Store pairs especially on a 64 bit architecture?


A load pair takes one address generation and one slot in the load queue but returns 2 x 64-bit. It doubles your load throughput at the cost of the complications from an instructions that return two results.

Apple's A14 can issues three loads per cycle. Assuming they can all be load pairs (I don't know currently) that would be 6 loads per cycle. This is frighting :)

The story is similar for store pairs, but probably less important as stores are rarely on the critical path.


Thanks.

I imagine that the complexity coming from implementing load/store pairs will probably be dwarfed by RISCV's forthcoming SIMD and Vector extensions.


Hmm, it's hard to say (and a lot depends on how performant you make the vector loads) but it's really not comparable as the load pairs target any arbitrary (and renamed) architectural registers, whereas the vector load targets a different register file and just a single vector (= much more regular).


What exactly makes RISC-V easier to implement? Is it only about fewer instructions? Or is it as much or more about the semantic s and simplicity of the instructions you got to implement?

Is it possibly to point out some important things that increase the complexity noticeably in implementing ARM?


I haven't even attempted to implement AArch64 and only browsed the ISA, but it's all of these things. Instructions are many and some semantics that are more painful, like handling flags which are exactly like mini registers and the load pair/store pair instructions I mentioned. Also, there are more addressing modes which puts pressure on the load path. All this complexity hurts even more when it comes to verification.


RISC-V has a tiny basic instruction-set consisting of very simple instructions. That makes it possible to implement a RISC-V core on a very small silicon die. Smaller simpler cores make it easier to increase clock frequency as well as reduce watt usage. That gives RISC-V an advantage over the competition such as ARM, where any implementation will require a much larger and complex core to handle all the ARM instructions you must implement to be a valid ARM CPU.


It won’t happen. People (aka businesses) want something that just works for the person doing data entry or scheduling calendars and expects the code rguy (even if a top 3 in the world by value by valuation) to suck it up to bare bottom IT policy.

My opinions are my own. But the things one sees coming from them, they make things up to justify their continued existence.




Consider applying for YC's Fall 2026 batch! Applications are open till July 27.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: