each vendor’s CPU design can differ vastly from one another unlike x86 which is standard and only between amd and Intel.

The ISA guarantees that a program compiled for it can run on any of these vendor designs. For example native binaries for Android run on any SoC from any vendor with the ARM ISA compiled for. The situation is exactly the same as with x86, Intel and AMD. Their core designs are very different yet binaries compiled for x86 run on either Intel or AMD, and on any of their models, even across different architectures. E.g. a binary compiled for x86_64 would run on AMD Zen 2, as well as Intel Skylake, as well as AMD Bulldozer.

How is RISC-V better at this?

It’s better in that it’s free to use. Anyone making a chip implementing RISC-V doesn’t have to pay ARM or Intel for a license. Not that Intel sells them anyway.

The fragmentation issue might become a new problem. With that said we definitely want to move away from the only usable cores using ARM or x86, neither of which we can design and manufacture without the blessing of two corpos, one of which is a proven monopoly abuser.

Shortest answer is that RISC-V is Open Source and ARM is proprietary but what does that mean?

First, it means “freedom” for chip makers. They can do what they want, not what they are licensed to do. There are a lot of implications to this so I will not get into all of them but it is a big deal. There is even a standard way of adding ISA extensions. It makes RISC-V an interesting choice for custom chip makers trying to position themselves as a platform ( think high-end, specialty products ).

If you are a country or an economy that is being hit with trade restrictions from the Western world ( eg. China ), then the “freedom” of RISC-V also provides you away around potentially being denied access to ARM.

For chip makers, the second big benefit is that RISC-V is “free” as in beer—no licenses. For chips in laptops or servers, the ISA license is a small part of the expense per unit. But for really high-volume, low-cost use cases, it matters.

In the ARM universe, middle of the market chip makers license their designs off of ARM ( not just the ISA ). This is why you can buy “Cortex” CPUs from multiple suppliers. Nobody else can really occupy this space other than ARM. In the RISC-V universe, you can compete with ARM not just selling chips but by licensing cores to others. So, you get players like StarV and MilkV that again want to be platforms.

So, RISC-V is positioned well across the spectrum—somewhat uniquely so. This makes it an excellent bet for building software and / or expertise.

It is only the ISA that is Open Source though. Unlike some of the other answers here imply, any given RISC-V chip is not required to be any more open than ARM. The chip design itself can be completely proprietary. The drivers can be proprietary. There is no requirement for Linux support, etc. That said, the “culture” of RISC-V is shaping up to be more open than ARM.

Perhaps because they want to be platforms, or perhaps because RISC-V is the underdog, RISC-V companies are putting more work into the software for example. RISC-V chip makers seem more likely to provide a working Linux disto for example and to be working on getting hardware support into the mainline kernel. There is a lot of support in the RISC-V world for standards for things like firmware and booting.

With the exception of RaspberryPi, the ARM world is a lot more fractured than RISC-V. You see this in the non-Pi SBC world for example. That said, if we do consider just RaspberryPi, things are more unified there than in RISC-V.

Overall, RISC-V may be maturing more quickly than ARM did but it is still less mature overall. This is most evident in performance. Nobody is going to be challenging Apple Silicon or Qualcomm X Elite with their RISC-V chips just yet. Not even the Pi is really at risk.

Eventually, we will also just get completely Open Souce designs that anybody can implement. These could be University research. They could be state funded. They could be corporately donated designs ( older generations maybe ). Once that starts to happen, all the magical things that happened for Open Source software will happen for RISC V as well.

Open Source puts a real wind at RISC-V’s back though. And no other platform makes as much sense from the very big to the very small.

Yes. Less blobs than ARM. I’m not even sure if some RISC-V have any blobs – someone correct me if I’m wrong.

Also getting cockblocked by proprietaryisms is bullshit. HDMI is a Circle Jerk of capitalism controlling competition and the market for self preservation.

Actually, I think RISC-V is even worse than ARM. With ARM, at least you have a quite reliable instruction set on the CPU. With RISC-V, most vendors have their own extensions of the instruction set, which opens a big can of worms: Either you compile all your stuff for your own CPU, or you have a set of executables for each and every vendors flavor of RISC-V commands, or you exclusively use the RISC-V core commands. The first would be only for hardcore geeks, the second would be a nightmare to maintain, and the third would be not really efficient. Either way, it sucks.

I don’t think there has been huge issues with incompatible ISAs on ARM. If you’d use NEON extensions, for example, you might have a C-implementation that does the same if the extensions are not available. Most people don’t handwrite such code, but those that do usually go the extra mile. ARM SoCs usually have closed source drivers that cause headaches. As well as no standardized way of booting.

I haven’t delved super-deep into RISC-V just yet, but as I understand these systems will do UEFI, solving the bootloader headache. And yes, there are optional extensions and you can even make your own. But the architecture takes height for implementing an those extensions in software. If you don’t have the gates for your fancy vector instruction, you can provide instructions to replicate the same. It’ll be slower on your hardware, but it’ll be compatible if done right.

i’ve had the same thought lately. the common arm design approach around the bootloader seems to turn old Android phones and tablets into e-waste sooner than necessary, in theory they could all run Linux and be useful for another ten years. but it’s hard enough to port mainline Linux to Android devices, and almost impossible to get all the included hardware working properly

deleted by creator