The CPU is one of the most crucial components of our computers, responsible of performing basic calculations, logical comparisons and moving data around. These simple tasks are the building blocks of any more complex operation, and make running our systems and programs possible.

How these operations are done is not random: an Instruction Set Architecture (ISA) defines what they are and what computer processors are supposed to do.

An ISA defines supported instructions and features, but not how these instructions are specifically carried out. Think of it like a cooking recipe -- let's say it's for bagels: while the recipe is the same, each chef will carry it out differently, arranging the sesame seeds differently for instance. The chef cooking based on the recipe is, in our example, the computer processor carrying out instructions as per the defined ISA. The result will always be the same in theory, though: a tasty bagel.

A different instruction set may not define boiling water directly, but lets you do certain operations on objects instead: heat, measure and compare. A chef would now have to heat up water and compare its measured temperature with the known boiling temperature. There are two main architecture types for processors: Complex Instruction Set Computing (CISC) and Reduced Instruction Set Computing (RISC).

Simply put, CISC's goal is to make things easier for programmers (offering an instruction to boil water, another to heat up oil, etc) at the cost of larger processors, while RISC tries to have a simpler set of instructions, requiring some more effort from programmers but resulting in smaller processors and less power consumption. Because of the two architectures having different capabilities, a program that runs on one must usually be rewritten to run on the other. One of the most popular architectures today on smartphones is part of the RISC family: ARM, which stands for Acorn RISC Machine.

It's worth noting that this mostly applies to programming/porting compilers. For other purposes such as making a user program, you'd normally use a high-level language which is somewhat comparable to CISC on a software level. Another important note is that this comparison is aimed at giving you a simple but intuitive understanding of these concepts. An accurate, in-depth explanation would be much longer and more technical.

This finally brings us to RISC-V (pronounced "risk five"), which is a free and open source ISA for SoCs (Systems-on-a-Chip, which basically packages the CPU and other necessary components to run a system together). Most other ISAs such as the ones by Intel, IBM or ARM are proprietary and cannot be used by others without licenses (which can take up to a couple of years to negotiate). On the other hand, RISC-V can be used, implemented and produced by anyone, for free, with the only real condition being to acknowledge the RISC-V authors.

This allows independent researchers and developers to implement their own processors or modify open source RISC-V implementations, something that isn't possible with an ARM license for example (a separate license is required for that, which around 15 big companies have). At the same time, the ISA can also be extended and modified by companies without releasing the source code, in a comparable fashion to Android. The absence of licensing fees also means cheaper processors, though that won't decrease smartphones' prices much in practice even if RISC-V becomes widely used in the long term: the royalty on SoCs simply doesn't make up a huge portion of a smartphone's cost (Qualcomm takes 2.5—5% of the selling price as royalties, for example).

RISC-V isn't the first free ISA, as others exist as well. The most popular and most actively developed of the others is OpenRISC, which started in 2000 and is released under the GNU GPL. Ignoring other differences, the permissive license of RISC-V makes it more plausible to be adopted by larger companies and it making a difference. For example, Google, Hewlett-Packard Enterprise (HPE) and Oracle are three bigger companies that have recently joined the RISC-V standard working group, effectively showing their interest in RISC-V as an open standard. As long as all implementations adhere to the specifications ("RISC-V compliant"), customers would still be able to use one ecosystem or another (e.g. GNU/Linux) in theory, while companies would have an incentive to do so to avoid having to write or port their systems from scratch. At the same time, RISC-V gaining traction means smaller companies can actually support the open source community while still having a flexible system (one such company interested in RISC-V is lowRISC).

It remains to be seen whether RISC-V can bring actual improvements or not for customers who may be interested in having open systems, or running any supported operating system on compliant SoCs. At the same time, there are other potential concerns than RISC-V's traction: while the permissive license comes with certain benefits, it could also enable giants to use the Embrace, Extend and Extinguish strategy (which is arguably the case when it comes to Android/AOSP and Google's services, or even Android Wear) -- though one might argue that would still be better than the current situation. A comparison could even be drawn between that and the Android scene today, with various OEMs trying to differentiate their skins to gain more users, and custom ROM communities persisting for power users.

Visit the RISC-V webpage if you want to find out more about the project's history and goals, or to even try a RISC-V implementation yourself.