RISC-V isn’t as interesting as you think

I had wrote this before the Unleashed was revealed, so some of the bits on economics have changed. As of writing this, I still stand by my other beliefs. One of the most hyped things in hardware design is RISC-V, the open ISA available without license fees. Many organizations including Western Digital have pledged support for RISC-V, and the open source community has a lot of faith in it, and with Nvidia’s recent purchase of Arm, people are concerned. However, I feel these hopes are somewhat misleading, as RISC-V’s openness is less at the benefit of the user and more for CPU vendors.

Royalties. One of the biggest benefits of RISC-V is not having to pay any royalties for a CPU using it. You might pay SiFive or someone else for a realization of their cores on hard silicon, but that’s for the design, not an abstract implementation of the ISA. Openness here means there’s more profit margin on the tiny chips running washing machines, since they don’t have to pay ARM or Synopsys. While the savings could be passed onto you, the ISA’s openness will never be of concern when the program is on a one-time-programmable ROM.

ISA fragmentation. RISC-V intentionally defines a small ISA with extensions (for example, multiplication, which actually encompasses divide too… which is even more expensive to implement than multiply, but it’s a package deal). While most larger implementations will implement a common set of extensions, having basic functionality in extensions could make software compatibility for binary distributions harder. This is made worse by RISC-V explicitly encouraging custom instructions for task-specific tweaks on vendor silicon – great for embedded, not so hot for general purpose computers and operating systems supporting them.

Economics. RISC-V has actively courted embedded, which makes sense as a niche. Much of the hype of RISC-V is hoping for laptop/desktop/server class silicon. This is unlikely, because the economics of embedded are different. ISA doesn’t matter as much in embedded programming (code reuse matters, but it’s not like you’re running arbitrary binaries), whereas user/enterprise focused computing usually lives and dies by binary compatibility (to protect investments in existing applications) and performance gained by things most RISC-V implementations don’t have yet like superscalar execution (To say nothing how these impact implementation complexity and security!).

Openness doesn’t tickle down. The openness of an ISA doesn’t have much impact on the implementation. A design with restricted signing keys is completely acceptable under their licensing – and is very likely, considering the embedded dominance RISC-V is likely to have. There are no guarantees of openness in ways that impact a user (i.e controlling the root of trust), since a user doesn’t exactly have access to a fab.

Design flaws. RISC-V seems like it hasn’t learned anything from CPUs designed after 1991. Between some rookie mistakes like few addressing modes (register churn, code density) and blowing out the encoding space. However, despite its flaws, it’s poised to take over embedded and possibly beyond anyways – worse truly is better.

Overall, RISC-V will lead in a revolution for nationalist vanity CPUs (think Loongson; no one will run them but for show and perhaps a niche of radical ideologues) , academic projects, and embedded vendors wanting to save on their balance sheets, but it probably won’t affect users or developers.

3 thoughts on “RISC-V isn’t as interesting as you think

  1. Stephen Wake February 2, 2021 / 9:44 am

    Acorn Risc Machine -> ARM Embedded -> Apple Phone Silicon -> Apple Laptop Silicon M1 -> Apple Desktop Silicon

    ARM took a long time to evolve, Apple has drastically ramped that up, no one wants a laptop that only lasts half a day when they can have an equal or better performance from one that lasts a full day with spare juice left over. It’s not just about the core ISA(s), it’s about being able to extend the ISA with new types of execution units, GPUs, KPUs, Encryption, Vector, Codecs etc and have them all integrate into a customised ISA seemlessly, if not on the same chip on the same package without having to treat each as an external device. I’m not sure of the Licensing requirements but good citizens will contribute back their hardware designs and ISA extensions back to the community. Instead of one GPU implementation there might be 5 which have different strengths and TDPs, but with the same or very similair ISA. Vulkan api could be implemented in an ISA.

  2. Attila Kinali February 4, 2021 / 8:20 am

    Apropos ISA fragmentation, have you checked the number of your CPU flags recently?

    Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault invpcid_single ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm mpx rdseed adx smap clflushopt intel_pt xsaveopt xsavec xgetbv1 xsaves dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp md_clear flush_l1d arch_capabilities

    Each one of these represents an ISA extension. Each one of those needs to be checked by an application that makes use of them. But for some reason, with x86 it isn’t a problem but for RISC-V it is?

    And for the “niche thing”, the 68HC05 is, as far as I know, still the most sold processor (last number I found was 5 billion sold in 2001). Intel can only compete with that, if you add up all their processors together.

    • cb February 4, 2021 / 6:14 pm

      The x86 encodings don’t overlap, aren’t as profilic, are supported by most processors, or are very niche, as far as I know.

Leave a Reply

Your email address will not be published.