RISC-V: The Open ISA Revolution and the Cambrian Explosion of Processor Design

In the summer of 2010, a group of researchers at UC Berkeley sat down to design a new microprocessor. This was not unusual; Berkeley had been designing processors — RISC-I, RISC-II, SPUR — since David Patterson coined the term “RISC” in the early 1980s. What made this project unusual was that they were not primarily trying to build a faster processor. They were trying to build a better instruction set. And because the obvious response to “why not use x86 or ARM?” was “because those are proprietary and we want to do research,” they decided their new ISA would be open — freely usable by anyone, for any purpose, without royalties, without license negotiations, without lawyers.

That project became RISC-V (pronounced “risk-five”), and in the fifteen years since, it has triggered what can only be described as a Cambrian explosion in processor design. Startups that could never have afforded an ARM architecture license — which runs into the tens of millions of dollars for a high-end core — are designing custom RISC-V processors for applications ranging from IoT sensor nodes to data center accelerators. The European Union is funding RISC-V supercomputer initiatives. India has declared RISC-V its national ISA. And the RISC-V Foundation, now RISC-V International, has grown to over 4,000 members across 70 countries.

What makes RISC-V interesting is not that it is open — OpenRISC, OpenSPARC, and several other open ISAs predate it. What makes it interesting is that it is good: cleanly designed, modular, extensible, and informed by decades of hindsight about what works and what does not in instruction set architecture. The base integer ISA fits on a single page. The extension framework allows everything from tiny 32-bit embedded cores to massive 64-bit vector machines, all sharing a common software ecosystem. And the governance model — RISC-V International as a Swiss nonprofit, with technical decisions made by member-driven task groups — has managed to avoid both the paralysis of committee design and the chaos of fragmentation.

This post is a deep dive into RISC-V from a systems and architecture perspective. We will walk through the base ISA, the extension framework, the vector extension (RVV) that aims to replace proprietary SIMD with something genuinely elegant, the CHERI-RISC-V security story that may redefine memory safety, and the ecosystem dynamics that will determine whether RISC-V fulfills its promise or becomes another footnote in the history of failed open hardware projects.

1. The Base ISA: RV32I and RV64I

At the heart of RISC-V is a deceptively simple integer ISA. RV32I — the 32-bit base integer instruction set — defines 40 instructions. Forty. That is the entire mandatory core: loads, stores, integer arithmetic, shifts, logical operations, branches, jumps, and a handful of system instructions. For comparison, the x86-64 ISA manual runs to over 2,000 pages and defines something on the order of 1,500 instructions. ARMv8-A is smaller but still defines hundreds. RISC-V’s designers made a deliberate aesthetic choice: the base ISA should be minimal, orthogonal, and sufficient to run a reasonable operating system. Everything else — floating-point, atomics, vectors, compressed instructions, virtualization — is an optional extension.

Here is the RV32I instruction encoding layout:

    31    30 ... 25  24 ... 20  19 ... 15  14 ... 12  11 ... 7  6 ... 0
    +-----+---------+----------+----------+----------+---------+--------+
    |funct7|   rs2   |    rs1   |  funct3  |    rd    |  opcode |
    +-----+---------+----------+----------+----------+---------+--------+
        7       5          5          3         5          7

Four major opcode formats — R-type, I-type, S-type, U-type — with a handful of minor variants. The regularity of this encoding is not an accident; it is a reaction to the irregularity of x86, where the instruction length varies from 1 to 15 bytes and the decoder must essentially guess where instructions start. RISC-V instructions are always 32 bits wide in the base ISA (16 bits for the compressed extension), which means the decoder can be simple, fast, and small — an important consideration for embedded cores where every gate counts.

The register file has 31 general-purpose registers (x1 through x31) plus x0, which is hardwired to zero. This is a classic RISC design choice: register x0 discarding writes and reading as zero eliminates the need for a separate nop instruction (you just write addi x0, x0, 0) and simplifies many common idioms (setting a register to zero, computing a negation, implementing mov as addi rd, rs, 0). The calling convention assigns specific roles: x1 is the return address (ra), x2 is the stack pointer (sp), x5 through x7 and x28 through x31 are temporaries, and x8 through x9 and x18 through x27 are saved registers.

The base ISA distinguishes between RV32I (32-bit), RV64I (64-bit), and RV128I (128-bit — defined but not yet implemented in silicon). RV64I adds a handful of word-wide (32-bit) variants of the integer instructions — addiw, slliw, srliw, sraiw — plus the ld and sd doubleword load/store instructions. The transition from 32-bit to 64-bit is clean: the same instruction encodings work, with the width determined by the processor mode.

One of the most contentious design decisions in RISC-V was the absence of condition codes. Most architectures — x86, ARM, MIPS — have a condition code register (or flags) that is set by arithmetic instructions and read by conditional branches. RISC-V dispenses with this entirely. Branches compare two registers directly: beq rs1, rs2, offset branches if rs1 == rs2. This costs an extra register read on branches but eliminates the condition code register as a serialization point — you can issue a branch and the arithmetic it depends on in the same cycle without worrying about flag hazards. For a superscalar implementation, this is a significant simplification.

Another deliberate omission: there is no zero flag, no carry flag, no overflow flag. If you need to detect overflow on an addition, you use a separate instruction or check the operands manually. This choice reflects the RISC-V philosophy of not providing hardware support for operations that compilers rarely use or that can be synthesized cheaply.

2. The Extension Framework: Alphabet Soup with Purpose

Beyond the base ISA, RISC-V defines a family of standard extensions, each identified by a single letter. The combination of base ISA and extensions forms an ISA string — like RV64IMAFDC — that precisely specifies the processor’s capabilities. The key standard extensions are:

• M — Integer multiplication and division. Adds mul, mulh, mulhu, mulhsu, div, divu, rem, remu. Notably, multiplication produces a double-width result (e.g., 32×32 → 64 on RV32), with separate instructions for the high and low halves. This is cleaner than x86’s implicit EDX:EAX destination register pair.

• A — Atomic memory operations. Provides load-reserved (lr.w) and store-conditional (sc.w) for building locks, plus atomic read-modify-write operations (amoswap, amoadd, amoand, etc.). These are essential for multicore systems where you need atomic updates to shared memory.

• F — Single-precision floating-point. Adds 32 floating-point registers (f0-f31), load/store, arithmetic, comparison, and conversion instructions. The floating-point registers are separate from the integer registers — a choice that simplifies the register file design (no need to handle both integer and FP data in the same physical register file) but complicates the calling convention.

• D — Double-precision floating-point. Extends the F extension to 64-bit operations.

• C — Compressed instructions. Adds 16-bit instruction encodings for the most common operations, reducing code size by 25-30% at essentially zero hardware cost. This is one of RISC-V’s killer features: the compressed instructions are not a separate mode; they coexist transparently with 32-bit instructions, and the processor fetches and decodes them as a stream of arbitrary-length parcels.

• V — Vector extension. This is a big deal and deserves its own section. See below.

• H — Hypervisor extension. Adds support for virtualizing RISC-V guests, including two-stage address translation, virtual interrupts, and the hstatus/htval/htinst CSRs for trap handling.

• S — Supervisor-level ISA. Defines the privilege levels (machine, supervisor, user) and the control and status registers (CSRs) that manage them. This is not really an “extension” in the same sense as M or F — it is required for any system that runs an OS — but it is documented as one for consistency.

The extension framework is what makes RISC-V commercially viable. A vendor designing a tiny embedded microcontroller can implement just RV32IMC and get a fully functional, standards-compliant processor that runs standard RISC-V software (minus floating-point and atomics). A vendor designing a data center accelerator can implement RV64IMAFDCV and get a fully featured vector machine. Both use the same toolchain, the same compiler, the same ecosystem. This is fundamentally different from the ARM world, where Cortex-M and Cortex-A processors are architecturally incompatible — you cannot run ARMv8-A binaries on a Cortex-M0.

The non-letter part of the extension framework is equally important. Custom extensions — X-prefixed — allow vendors to add proprietary instructions without breaking compatibility. SiFive, one of the leading RISC-V IP vendors, has added custom vector instructions for machine learning. Esperanto has added custom instructions for branch prediction hints. The beauty is that these custom extensions can coexist with the standard ones, and a processor that encounters an unknown custom instruction will trap (if the trap mechanism is configured), allowing software emulation. This is a deliberate escape valve: it lets the ecosystem innovate without fragmenting the standard.

3. The Vector Extension (RVV): SIMD Done Right

If there is one technical feature of RISC-V that has the potential to reshape computing, it is the vector extension — RVV, or officially “V” extension, version 1.0 ratified in 2021. To understand why RVV matters, we need to understand what is wrong with the SIMD instruction sets it aims to replace.

Every major architecture has a SIMD extension. x86 has MMX, SSE (1 through 4.2), AVX, AVX2, and AVX-512 — six generations of increasingly wide, increasingly complex SIMD ISAs, each with a different register width (64, 128, 256, 512 bits), different instruction mnemonics, and different rounding and exception behavior. ARM has NEON (128-bit) and SVE (scalable vector extension, up to 2048 bits). The fundamental problem with all of these is that they fix the vector width in the ISA. Code written for AVX-512 will not run on a processor that only supports AVX2. Code written for NEON will not take advantage of an SVE-capable processor without recompilation. The ISA and the microarchitecture are coupled in a way that makes software portability — and hardware evolution — difficult.

RISC-V’s vector extension decouples them. An RVV implementation defines a vector length (VLEN) that is implementation-specific but architecturally visible. Vector registers are VLEN bits wide. Vector instructions operate on elements whose size is specified by the instruction (8, 16, 32, or 64 bits), and the number of elements processed depends on VLEN. A vector add of 32-bit integers on a VLEN=256 processor processes 8 elements per instruction; on a VLEN=1024 processor, it processes 32 elements — with the same binary code. The magic is in the vsetvli instruction, which configures the vector length for a subsequent block of vector instructions:

    vsetvli t0, a0, e32, m1   # Set vector length: 32-bit elements, 1 register group
    vle32.v v1, (a1)           # Load vector from memory
    vle32.v v2, (a2)           # Load another vector
    vfadd.vv v3, v1, v2        # Vector floating-point add
    vse32.v v3, (a3)           # Store result

This code runs identically on any RVV implementation, regardless of VLEN. The hardware processes as many elements per instruction as its vector registers can hold, and if the application-specified vector length (a0 in the example) is larger than VLEN, the software loops — this is called strip-mining, and it is entirely transparent to the application.

RVV supports several advanced features that go beyond simple packed-SIMD:

• Register grouping (LMUL). Multiple vector registers can be combined into a single logical register group. LMUL=2 pairs two registers, doubling the effective vector length. LMUL=8 combines eight. This allows the programmer to trade register count for vector length, which is useful for operations like matrix multiply that require accumulating many partial sums.

• Masked execution. Every vector instruction can be predicated on a mask register. Mask elements are single bits, packed into a vector register. A masked vfadd.vv v3, v1, v2, v0.t adds only those elements where the corresponding mask bit in v0 is set. This is essential for vectorizing loops with conditionals.

• Gather/scatter. Indexed loads and stores allow non-contiguous memory access. vlxei32.v v4, (a0), v2 loads elements from addresses computed as base a0 plus each element in the index vector v2. This is the vector equivalent of a[i] = b[c[i]] and is critical for sparse matrix operations.

• Vector reduction. Operations like sum, max, and logical-AND across all elements of a vector are supported directly.

• Permutation. Arbitrary element rearrangement, including slide, insert, extract, and register-register gather.

The design philosophy behind RVV is worth examining because it represents a masterclass in ISA design. The core insight is that vector ISAs should specify behavior in terms of element counts, not register widths. The vsetvli instruction acts as a contract between software and hardware: software says “I want to process N elements of size E,” and hardware says “I can process M elements at a time, where M ≤ N and M × E ≤ VLEN.” The hardware’s response — the actual vector length — is written to a general-purpose register, and the software loops over the remaining N - M elements. This is exactly how Cray vector supercomputers worked in the 1970s, and it is one of those ideas that was so obviously right that it seems inevitable in retrospect.

The comparison with ARM’s SVE is instructive. SVE also decouples vector width from the ISA — it was announced in 2016, five years before RVV 1.0 was ratified. But SVE is proprietary ARM intellectual property, available only to ARM licensees, and its toolchain ecosystem is tightly coupled to ARM’s proprietary compilers and libraries. RVV provides the same decoupling (plus several features SVE lacks, like the variable-length element concept) but in an open, multi-vendor ecosystem where anyone can build a compliant implementation. This is the open-source advantage applied to ISA design: not just freedom from licensing fees, but freedom from single-vendor control of the software ecosystem.

4. The Implementation Landscape: From Breadboards to Supercomputers

RISC-V processors now span an extraordinary range of the performance/power/cost space. Here is a rough taxonomy:

Embedded microcontrollers (RV32IMC). At the low end, RISC-V cores are displacing ARM Cortex-M in embedded applications. SiFive’s E2 series and the open-source PULPino/Ibex cores provide 32-bit in-order pipelines with optional compressed instructions. These cores are tiny — 10-50 kilogates — and are appearing in everything from SSD controllers to automotive sensor hubs. Western Digital has committed to shipping a billion RISC-V cores per year in its storage products. The economics are compelling: eliminating ARM’s per-unit royalty (typically a few cents) saves millions of dollars at scale.

Applications processors (RV64IMAFDC). SiFive’s U7 series and the open-source BOOM (Berkeley Out-of-Order Machine) provide multi-issue, out-of-order 64-bit cores suitable for running Linux. The U74, used in the HiFive Unmatched development board, is a dual-issue in-order core (with a separate out-of-order vector unit) that delivers roughly ARM Cortex-A55-class performance. The P550, announced in 2021, is a 3-wide out-of-order core targeting the performance level of a Cortex-A75. This is still several generations behind the state of the art (Apple’s M-series cores are wider, deeper, and clocked higher), but the gap is closing.

Vector accelerators. RVV implementations are emerging from multiple vendors. SiFive’s X280 is a multi-core vector processor targeting data center inference, with a 512-bit VLEN and support for FP16, BF16, and INT8 data types. Esperanto’s ET-SoC-1 integrates over 1,000 RISC-V cores — a mix of high-performance 64-bit out-of-order cores and energy-efficient in-order cores with vector units — on a single chip, targeting machine learning inference. Ventana Micro Systems is developing RISC-V chiplets for data center servers. The common thread is that RVV enables these vendors to build vector processors without having to also design a proprietary SIMD ISA.

Academic and research processors. RISC-V’s openness has made it the ISA of choice for architecture research. The Berkeley FireSim project provides a cycle-accurate FPGA-accelerated simulator for RISC-V processors. The Chipyard framework integrates RISC-V core generators with a full SoC design environment. The OpenROAD project provides an open-source digital design flow from RTL to GDSII. Collectively, these tools have dramatically lowered the barrier to entry for custom silicon design. A graduate student can now design a RISC-V processor, tape it out on a multi-project wafer shuttle (like Google’s Open MPW program, which provides free fabrication on SkyWater’s 130 nm process), and have working silicon in a few months. This was unthinkable even ten years ago.

Supercomputers. The European Processor Initiative (EPI) is developing a RISC-V-based accelerator for exascale computing. The EPAC (European Processor Accelerator) chiplet integrates RISC-V vector cores with a high-bandwidth memory interface and a network-on-chip designed for HPC workloads. India’s VEGA series of RISC-V processors, developed by C-DAC, targets both embedded and HPC applications. The Barcelona Supercomputing Center has ported its OmpSs programming model to RISC-V. These are not toy projects; they are serious attempts to build production HPC infrastructure on an open ISA.

5. The CHERI-RISC-V Security Story

Perhaps the most consequential extension to RISC-V — in terms of its potential to change how we build secure systems — is CHERI, the Capability Hardware Enhanced RISC Instructions. Developed at the University of Cambridge and SRI International over the past decade, CHERI extends a conventional RISC ISA with hardware-enforced capabilities: unforgeable tokens that grant access to specific memory regions with specific permissions. CHERI has been implemented on MIPS, on ARM (as part of the Morello prototype), and most recently on RISC-V, where it is being standardized as the Zcheri extension.

The problem CHERI solves is fundamental. Despite fifty years of progress in programming languages, operating systems, and processor architecture, memory safety errors — buffer overflows, use-after-free, null pointer dereferences — remain the dominant source of security vulnerabilities. The Chromium project reports that 70% of its high-severity security bugs are memory safety issues. Microsoft reports similar numbers for Windows. These are not problems of careless programming; they are problems of an architectural model — the flat virtual address space — in which any pointer can access any address within the process’s address space, and there is no hardware-enforced distinction between a legitimate pointer to a valid object and an attacker-crafted pointer that happens to overlap with something sensitive.

CHERI replaces flat pointers with capabilities: 128-bit (or 64-bit compressed) values that encode a base address, a bound, and a set of permissions. A capability is created only by authorized code (typically the OS kernel or the runtime loader) and cannot be forged — the capability registers are distinct from the general-purpose registers, and there is no instruction to construct an arbitrary capability from raw bits. Capabilities are monotonically attenuated: you can derive a capability with tighter bounds or fewer permissions from an existing capability, but you cannot widen bounds or add permissions. A load or store through a capability is checked in hardware: if the address falls outside the capability’s bounds, or if the permission bits do not allow the access, the processor traps.

Here is a simplified view of the CHERI capability format:

    127 ... 108  107 ... 88  87 ... 64  63 ... 0
    +-----------+-----------+----------+---------+
    | perms     | otype     | bounds   | address |
    +-----------+-----------+----------+---------+
        20 bits    20 bits    24 bits    64 bits

The compressed 64-bit format uses a different encoding — essentially, the capability encodes the address and a compressed representation of the bounds that is decompressed on use. This allows CHERI to provide memory safety with reasonable overhead: 128-bit capabilities roughly double the size of pointers, which increases cache pressure, but the hardware bounds checking adds only a few percent to the critical path of a load instruction. The ARM Morello prototype — a CHERI-enhanced ARMv8-A processor — demonstrated that the overhead is manageable: a full desktop environment (KDE on FreeBSD) running in pure-capability mode incurred roughly 10-15% performance overhead, with most of that attributable to the increased memory footprint rather than the bounds checking itself.

CHERI provides three critical guarantees that flat address spaces cannot:

1. Spatial memory safety. A capability defines a contiguous memory region. Any access outside that region traps. This prevents buffer overflows — the most common and most exploited class of memory safety bugs.

2. Temporal memory safety (via the load barrier). CHERI does not natively prevent use-after-free; a capability to a freed object remains valid in the architectural sense even after the object is deallocated. But CHERI provides a mechanism — the load barrier — that can be used with a sweeping memory allocator to revoke capabilities to freed memory. The allocator periodically scans memory for capabilities to freed objects and zeroes them (or marks them invalid), preventing dangling-pointer dereferences. This is not a complete solution to temporal safety, but it is a practical one that works with existing C/C++ code.

3. Fine-grained compartmentalization. Because capabilities control access to memory, they can enforce the principle of least privilege within a single address space. A library — say, an image decoder — can be given a capability that grants read access to the input buffer and write access to an output buffer, but no access to the rest of the process’s memory. If the decoder has a vulnerability, the attacker cannot use it to access sensitive data elsewhere in the process. This is a fundamentally different security model from the process-based isolation that Unix systems use today, and it enables much cheaper (in terms of context-switch overhead) compartmentalization.

The CHERI-RISC-V standardization effort is ongoing in the RISC-V International CHERI Task Group. The proposed Zcheri extension defines a set of capability registers, capability-aware load/store instructions, and the control-flow protections (sealed capabilities for jump targets) that together provide the CHERI guarantees on a RISC-V base. Because CHERI is an extension — not a new base ISA — it can be added to existing RISC-V implementations incrementally. The expectation is that CHERI will first appear in high-assurance systems (military, automotive, financial infrastructure) where the security benefits justify the hardware cost, and will gradually trickle down to general-purpose systems as the hardware overhead decreases with process scaling.

6. The Ecosystem: Compilers, Operating Systems, and the Boot Problem

An ISA is only as good as the software that runs on it. RISC-V has made impressive progress here, but the road has been rocky in places and there are still significant gaps.

Compilers. LLVM and GCC both have mature RISC-V backends. Clang/LLVM, in particular, has excellent support for RISC-V — better, arguably, than for any architecture other than x86 and ARM. The LLVM RISC-V backend supports all ratified extensions, including the vector extension (with auto-vectorization), and is actively maintained by a consortium of companies including SiFive, Google, and Igalia. GCC’s RISC-V support is solid but trails LLVM in terms of vectorization quality and the speed with which new extensions are supported. The Rust compiler has RISC-V support as a Tier 2 target, and the Go compiler added RISC-V support in Go 1.18.

Operating systems. Linux has had RISC-V support since kernel 4.15 (2018). The port is mature and supports all the features you would expect: SMP, virtual memory (Sv39, Sv48, and the new Sv57 57-bit virtual addressing), KVM virtualization, and a full set of device drivers (through the DeviceTree mechanism, the same as ARM uses). FreeBSD has a RISC-V port that is considered production-quality. Zephyr and FreeRTOS support RISC-V for embedded applications. The notable absence — for now — is Windows, though Microsoft has expressed interest and has been spotted hiring RISC-V engineers.

Boot and firmware. This is an area where RISC-V’s openness has been both a strength and a weakness. The ARM world has a well-defined boot flow: the processor starts executing from a fixed address, the boot ROM loads the first-stage bootloader, which loads UEFI firmware (like Tianocore), which loads the OS. RISC-V’s boot flow is more fragmented. The standard defines a simple mechanism: the processor starts executing at a fixed address (typically 0x8000_0000 for supervisor mode), and the firmware — usually OpenSBI (the RISC-V Supervisor Binary Interface) — provides a standard interface for the OS to discover hardware, handle interrupts, and manage privilege transitions. But the details of how the firmware gets loaded and how the device tree is passed to the OS vary across platforms. The RISC-V UEFI working group is addressing this, but for now, booting RISC-V Linux on a new platform is often an exercise in reading device tree source files and debugging OpenSBI.

Application ecosystem. The Debian RISC-V port is now an official architecture (riscv64), with over 90% of the Debian package archive compiled and functional. This is the classic measure of a platform’s maturity, and RISC-V has cleared it — not completely, but convincingly. The missing 10% is largely packages that have architecture-specific assembly (like the JVM’s JIT compiler, which needs a RISC-V code generator, or the V8 JavaScript engine, which added RISC-V support in 2022). These gaps are closing rapidly as RISC-V hardware becomes more available.

7. The Economics of Open ISAs

The technical merits of RISC-V are interesting, but the economic case is what drives adoption. To understand it, consider the cost structure of the ARM licensing model, which is the dominant alternative for anyone who wants a custom processor but does not want to pay Intel or AMD for an x86 chip (which, by the way, you cannot legally design yourself — the x86 ISA is protected by a web of cross-licensing agreements between Intel and AMD that effectively lock out third parties).

ARM charges an architecture license fee — reported to be in the $1-10 million range upfront, plus ongoing royalties — for the right to design a custom ARM-compatible core. You then pay a per-unit royalty (typically 1-2% of the chip’s selling price) on every chip you sell. If you instead license a standard ARM core design (like a Cortex-A78), you pay a higher per-unit royalty but avoid the upfront architecture license. Either way, ARM gets paid. This model has made ARM one of the most successful semiconductor IP companies in the world, but it also means that the ARM ISA is, fundamentally, a commercial product. You cannot fork it, you cannot modify it, and you cannot build an ARM-compatible processor without ARM’s ongoing cooperation.

RISC-V changes this calculus. The ISA is free. You can design a RISC-V processor without paying anyone a license fee. You can modify the ISA — adding custom extensions — without asking permission. You can fork the ISA if the RISC-V International steering committee makes a decision you disagree with (though the community strongly discourages this, and RISC-V International holds the trademark). The only cost is the engineering effort to design and verify the processor — which is substantial, but a one-time cost rather than a recurring royalty.

For a startup building a domain-specific accelerator — say, a processor optimized for computational photography or network packet processing — the RISC-V economics are transformative. Instead of spending $5 million on an ARM architecture license before writing a single line of RTL, you can spend that money on engineers who design a better processor. The result is a Cambrian explosion of processor startups — Esperanto, Tenstorrent, Ventana, Akeana, MIPS (yes, MIPS has switched to RISC-V), and dozens of others — that would not exist in a world where only ARM and x86 were viable options.

The counterargument is that the ARM ecosystem — compilers, debuggers, operating systems, libraries — is more mature, and that the per-unit royalty is a small price to pay for that maturity. This is true today but is becoming less true every year. The RISC-V ecosystem is catching up fast, and for many embedded applications (where the software stack is small and self-contained), it has already caught up. When a startup like Espressif — the company behind the ESP32 Wi-Fi microcontroller, which ships hundreds of millions of units — announces that its next-generation products will use RISC-V cores, it signals that the economic equation has tipped.

8. Architectural Comparisons: RISC-V vs. ARM vs. x86

A fair comparison must acknowledge that these three ISAs target different points in the design space and have different historical baggage.

RISC-V vs. ARM. ARM is a mature, well-designed RISC ISA that has evolved over 35 years. ARMv8-A (the 64-bit ARM ISA) is clean, orthogonal, and well-suited to both low-power and high-performance implementations. The main architectural difference between ARMv8-A and RISC-V is that ARM has accumulated more features — more addressing modes, more instruction variants, condition codes, SIMD (NEON and SVE) — while RISC-V has chosen to keep the base minimal and push features into extensions. Neither approach is inherently superior; they represent different design philosophies. The practical difference is that ARM is proprietary and RISC-V is open.

One concrete architectural comparison: ARM’s condition codes versus RISC-V’s register-register branches. ARM’s condition codes allow conditional execution of most instructions (in ARMv7 and earlier — ARMv8 dropped full predication but kept conditional branches). RISC-V’s register-register branches are simpler to implement but can require an extra compare instruction before each branch. The performance difference is negligible on modern out-of-order processors, where branches are predicted, but the hardware complexity difference is real: eliminating the condition code register simplifies the pipeline control logic.

RISC-V vs. x86. x86 is a CISC ISA with enormous historical baggage. Instructions vary from 1 to 15 bytes. The register file is small (16 general-purpose registers in x86-64) and has implicit operands for many instructions. The memory addressing modes are powerful (base + index × scale + displacement) but complex to decode. The x86-64 ISA also carries decades of legacy: real mode, protected mode, virtual 8086 mode, 16-bit and 32-bit operand size prefixes. And yet x86 processors are fast — Intel and AMD have spent billions of dollars and decades of engineering effort building microarchitectures that translate the messy x86 frontend into RISC-like micro-ops that execute efficiently. The lesson of x86 is that ISA quality matters less for performance than implementation quality, but ISA quality matters enormously for the cost and complexity of the implementation.

RISC-V’s designers learned this lesson. By keeping the ISA simple and regular, they reduced the effort required to build a high-performance implementation. A RISC-V out-of-order core can be simpler than an equivalent-performance x86 core because the decoder is trivial (every instruction is 32 bits, or 16 with the C extension, with a regular encoding) and there are fewer special cases to handle. Whether this simplicity translates into a competitive performance/power advantage remains to be seen — Intel’s and ARM’s implementation expertise is formidable — but the early evidence (from SiFive’s P550 and Ventana’s Veyron) suggests that RISC-V can be competitive in the mid-range performance segment.

9. Fractures and Risks

No honest assessment of RISC-V would be complete without discussing the risks. The open ISA model creates genuine challenges that the RISC-V community has not yet fully resolved.

Fragmentation. The RISC-V extension framework is powerful but dangerous. If every vendor adds their own custom extensions, the software ecosystem fragments. An application compiled for SiFive’s custom ML extension will not run on Esperanto’s processor, which has different custom extensions. RISC-V International mitigates this by requiring that custom extensions be non-conflicting (they must use reserved opcode space) and by encouraging vendors to upstream their extensions as standard extensions. But the economic incentive to differentiate through custom extensions is strong, and it is not clear that the standardization process can keep up.

Verification. Building a correct processor is hard. Building a correct RISC-V processor is easier than building a correct x86 processor (because the ISA is simpler), but it is still hard. The ARM ecosystem has decades of verification infrastructure — compliance test suites, formal models, validation farms — that RISC-V is still building. RISC-V International provides an architectural compatibility test suite, but it covers only the base ISA and the most common extensions, and it is not exhaustive. A vendor can claim “RISC-V compatible” without passing any certification process (there is no RISC-V equivalent of ARM’s “Architecture Compliance Kit”). This is a recipe for subtle incompatibilities that will frustrate software developers.

The geopolitical dimension. RISC-V’s openness is attractive to countries that want technological sovereignty — China, India, Russia, the EU. But this also means that RISC-V is influenced by geopolitical tensions. The US has export controls on semiconductor technology, and there is an ongoing debate about whether RISC-V — being an open standard developed in the US — falls under these controls. RISC-V International moved its headquarters from the US to Switzerland in 2020 partly to mitigate this risk, but the legal situation is murky. If export controls severely restrict RISC-V adoption in China, the ecosystem bifurcates: one RISC-V ecosystem for the West, another for China, with limited compatibility between them.

Patents. RISC-V International maintains a patent non-aggression policy: members agree not to assert patents against RISC-V implementations. But this only binds RISC-V International members. A patent troll who is not a member could still assert patents against RISC-V implementers. The risk is lower than for proprietary ISAs (because RISC-V is an open standard with disclosed specifications, making it harder to claim that an implementation inadvertently infringes), but it is not zero.

10. Summary

RISC-V represents something rare in computer architecture: a genuine inflection point. The combination of an open, well-designed ISA, a modular extension framework, and a rapidly maturing software ecosystem has created conditions that the semiconductor industry has not seen since the 1980s, when RISC itself was new and dozens of companies were designing their own processors before the market consolidated around x86 and ARM.

Whether RISC-V fulfills its promise depends on execution — on the ability of RISC-V International to manage the tension between standardization and innovation, on the ability of vendors to deliver competitive implementations, and on the software ecosystem’s willingness to treat RISC-V as a first-class target. The signs are promising. The momentum is real. And for computer architects, systems researchers, and anyone who cares about the future of computing hardware, RISC-V is the most exciting thing to happen in ISAs since David Patterson coined the term “RISC.”

The open-source revolution ate the software stack — operating systems, databases, compilers, languages. Now it is coming for the hardware. RISC-V is the Linux of instruction sets, and like Linux, its impact will be measured not in the dominance it achieves but in the innovation it unleashes.