 | This article'slead sectionmay be too short to adequatelysummarize the key points. Please consider expanding the lead toprovide an accessible overview of all important aspects of the article.(March 2025) |
 | |
| Designer | University of California, Berkeley |
|---|---|
| Bits | 32,64,128 |
| Introduced | 6 August 2014 (10 years ago) (2014-08-06)[1] |
| Version | |
| Design | RISC |
| Type | Load–store |
| Encoding | Variable |
| Branching | Compare-and-branch |
| Endianness | Little[2]: 9 [a] |
| Page size | 4 KiB |
| Extensions |
|
| Open | Yes, royalty free |
| Registers | |
| General-purpose |
|
| Floating point |
|
RISC-V[b] (pronounced "risk-five"[2]: 1 ) is anopen standardinstruction set architecture (ISA) based on establishedreduced instruction set computer (RISC) principles. The project commenced in 2010 at theUniversity of California, Berkeley. It transferred to the RISC-V Foundation in 2015, and from there to RISC-V International, a Swiss non-profit entity, in November 2019.[5][6] Similar to several other RISC ISAs, e.g.Amber (ARMv2) orOpenRISC, RISC-V is offered underroyalty-freeopen-source licenses.[7] The documents defining the RISC-V instruction set architecture (ISA) are offered under aCreative Commons license or aBSD License.
Mainline support for RISC-V was added to the Linux 5.17 kernel in 2022, along with itstoolchain.[8] In July 2023, RISC-V, in its64-bit variant called riscv64,[9] was included as an official architecture of Linux distributionDebian, in itsunstable version.[10] The goal of this project was "to have Debian ready to install and run on systems implementing a variant of the RISC-V ISA."[11]Gentoo also supports RISC-V.[12]Fedora supports RISC-V as an alternative architecture as of 2025.[13][14] TheopenSUSE Project added RISC-V support in 2018.[15]
Some RISC-V International members, such asSiFive,Andes Technology,Synopsys,Alibaba's Damo Academy,Raspberry Pi, and Akeana,[16][17] offer or have announced commercialsystems on a chip (SoCs) that incorporate one or more RISC-V compatible CPU cores.[18]
The termRISC dates from about 1980.[19] Before then, there was some knowledge (seeJohn Cocke) that simpler computers can be effective, but the design principles were not widely described. Simple, effective computers have always been of academic interest, and resulted in the RISC instruction setDLX for the first edition ofComputer Architecture: A Quantitative Approach in 1990 of whichDavid Patterson was a co-author, and he later participated in the RISC-V origination. DLX was intended for educational use; academics and hobbyists implemented it usingfield-programmable gate arrays (FPGA), but it was never truly intended for commercial deployment.ARM CPUs, versions 2 and earlier, had a public-domain instruction set and are still supported by theGNU Compiler Collection (GCC), a popularfree-software compiler. Three open-sourcecores exist for this ISA, but were never manufactured.[20][21]OpenRISC,OpenPOWER, andOpenSPARC /LEON cores are offered, by a number of vendors, and have mainline GCC andLinux kernel support.[22][23][24]
Krste Asanović at theUniversity of California, Berkeley, had a research requirement for an open-source computer system, and in 2010, he decided to develop and publish one in a "short, three-month project over the summer" with several of his graduate students. The plan was to aid both academic and industrial users.[25] David Patterson at Berkeley joined the collaboration as he was the originator of the Berkeley RISC,[19] and the RISC-V is the eponymous fifth generation of his long series of cooperative RISC-based research projects at the University of California, Berkeley (RISC-I andRISC-II published in 1981 by Patterson, who refers[26] to the SOAR architecture[27] from 1984 as "RISC-III" and the SPUR architecture[28] from 1988 as "RISC-IV"). At this stage, students provided initial software, simulations, and CPU designs.[29]
The RISC-V authors and their institution originally sourced the ISA documents[30] and several CPU designs underBSD licenses, which allow derivative works—such as RISC-V chip designs—to be either open and free, or closed and proprietary. The ISA specification itself (i.e., the encoding of the instruction set) was published in 2011 as open source,[31] with all rights reserved. The actual technical report (an expression of the specification) was later placed under aCreative Commons license to permit enhancement by external contributors through the RISC-V Foundation, and later RISC-V International.
A full history of RISC-V has been published on the RISC-V International website.[32]
Commercial users require an ISA to be stable before they can use it in a product that may last many years. To address this issue, the RISC-V Foundation was formed in 2015 to own, maintain, and publish intellectual property related to RISC-V's definition.[33] The original authors and owners have surrendered their rights to the foundation.[citation needed] The foundation is led by CEOCalista Redmond, who took on the role in 2019 after leading open infrastructure projects atIBM.[34][failed verification]
The founding members of RISC-V were:Andes Technology, Antmicro,Bluespec,Ceva,Codasip, Cortus, Esperanto Technologies,Espressif Systems,ETH Zurich, Google, IBM, ICT,IIT Madras,Lattice Semiconductor,LowRISC,Microchip Technology, theMIT Computer Science and Artificial Intelligence Laboratory,Qualcomm,Rambus, Rumble Development,SiFive, Syntacore and Technolution.[35]
In November 2019, the RISC-V Foundation announced that it would relocate to Switzerland, citing concerns over U.S. trade regulations.[36][37] As of March 2020, the organization was named RISC-V International, a Swiss nonprofit business association.[38]
As of 2019[update], RISC-V International freely publishes the documents defining RISC-V and permits unrestricted use of the ISA for design of software and hardware. However, only members of RISC-V International can vote to approve changes, and only member organizations use thetrademarked compatibility logo.[39]
The Linux Foundation Europe started the RISC-V Software Ecosystem (RISE) initiative on May 31, 2023. The goal of RISE is to increase the availability of software for high-performance and power-efficient RISC-V processors running high-level operating systems for a range of market segments by bringing together a large number of hardware and software vendors.Red Hat,Samsung, Qualcomm,Nvidia,MediaTek, Intel, and Google are among the initial members.[40]
 | This sectioncontainspromotional content. Please helpimprove it by removingpromotional language and inappropriateexternal links, and by adding encyclopedic text written from aneutral point of view.(March 2025) (Learn how and when to remove this message) |
CPU design requires design expertise in several specialties: electronicdigital logic,compilers, andoperating systems. To cover the costs of such a team, commercial vendors of processor intellectual property (IP), such asArm Ltd. andMIPS Technologies, chargeroyalties for the use of their designs andpatents.[42][43][44] They also often requirenon-disclosure agreements before releasing documents that describe their designs' detailed advantages. In many cases, they never describe the reasons for their design choices.
RISC-V was begun with a goal to make a practical ISA that was open-sourced, usable academically, and deployable in any hardware or software design without royalties.[2]: 1 [25] Also, justifying rationales for each design decision of the project are explained, at least in broad terms. The RISC-V authors are academics who have substantial experience in computer design, and the RISC-V ISA is a direct development from a series of academic computer-design projects, especiallyBerkeley RISC. RISC-V was originated in part to aid all such projects.[2]: 1 [25]
To build a large, continuing community of users and thereby accumulate designs and software, the RISC-V ISA designers intentionally support a wide variety of practical use cases: compact, performance, and low-power real-world implementations[2]: 1–2, 153–154 [45] without over-architecting for a givenmicroarchitecture.[2]: 1 [46][47][48] The requirements of a large base of contributors is part of the reason why RISC-V was engineered to address many possible uses.
The designers' primary assertion is that the instruction set is the key interface in a computer as it is situated at the interface between the hardware and the software. If a good instruction set were open and available for use by all, then it can dramatically reduce the cost of software by enabling far more reuse. It should also trigger increased competition among hardware providers, who can then devote more resources toward design and less for software support.[25]
The designers maintain that new principles are becoming rare in instruction set design, as the most successful designs of the last forty years have grown increasingly similar. Of those that failed, most did so because their sponsoring companies were financially unsuccessful, not because the instruction sets were technically poor. Thus, a well-designed open instruction set designed using well-established principles should attract long-term support by many vendors.[25]
RISC-V also encourages academic usage. The simplicity of the integer subset permits basic student exercises, and is a simple enough ISA to enable software to control research machines. The variable-length ISA provides room for instruction set extensions for both student exercises and research,[2]: 7 and the separatedprivileged instruction set permits research in operating system support without redesigning compilers.[3] RISC-V's open intellectual property paradigm allows derivative designs to be published, reused, and modified.[49]
RISC-V has a modular design, consisting of alternative base parts, with added optional extensions. The ISA base and its extensions are developed in a collective effort between industry, the research community and educational institutions. The base specifies instructions (and their encoding), control flow, registers (and their sizes), memory and addressing, logic (i.e., integer) manipulation, and ancillaries. The base alone can implement a simplified general-purpose computer, with full software support, including a general-purpose compiler.
The standard extensions are specified to work with all of the standard bases, and with each other without conflict.
Many RISC-V computers might implement the compressed instructions extension to reduce power consumption, code size, and memory use.[2]: 97–99 There are also future plans to supporthypervisors andvirtualization.[3]
Together with the supervisor extension, S, an RVGC instruction set, which includes one of the RV base instruction sets, the G collection of extensions (which includes "I", meaning that the base is non-embedded), and the C extension, defines all instructions needed to conveniently support a general purposeoperating system.[2]: 129, 154
| Name | Description | Version | Status[A] | Instruction count |
|---|---|---|---|---|
| Base | ||||
| RVWMO | Weak memory ordering | 2.0 | Ratified | |
| RV32I | Base integer instruction set, 32-bit | 2.1 | Ratified | 40 |
| RV32E | Base integer instruction set (embedded), 32-bit, 16 registers | 2.0 | Ratified | 40 |
| RV64I | Base integer instruction set, 64-bit | 2.1 | Ratified | 52 |
| RV64E | Base integer instruction set (embedded), 64-bit | 2.0 | Ratified | 52 |
| RV128I | Base integer instruction set, 128-bit | 1.7 | Open | 64 |
| Extension | ||||
| M | Standard extension for integer multiplication and division | 2.0 | Ratified | 8 (RV32) 13 (RV64) |
| A | Standard extension for atomic instructions | 2.1 | Ratified | 11 (RV32) 22 (RV64) |
| F | Standard extension for single-precision floating-point | 2.2 | Ratified | 26 (RV32) 30 (RV64) |
| D | Standard extension for double-precision floating-point | 2.2 | Ratified | 26 (RV32) 32 (RV64) |
| Zicsr | Control and status register (CSR) instructions | 2.0 | Ratified | 6 |
| Zifencei | Instruction-fetch fence | 2.0 | Ratified | 1 |
| G | Shorthand for the IMAFD_Zicsr_Zifencei base and extensions[2]: 129 | — | — | |
| Q | Standard extension for quad-precision floating-point | 2.2 | Ratified | 28 (RV32) 32 (RV64) |
| L | Standard extension for decimal floating-point | 0.0 | Open | |
| C | Standard extension for compressed instructions | 2.0 | Ratified | 40 |
| B | Standard extension for bit manipulation | 1.0 | Ratified | 29 (RV32) 41 (RV64)[50][51] |
| J | Standard extension for dynamically translated languages | 0.0 | Open | |
| T | Standard extension for transactional memory | 0.0 | Open | |
| P | Standard extension for packed-SIMD instructions | 0.9.10 | Open | |
| V | Standard extension for vector operations | 1.0 | Ratified | 187[52] |
| Zk | Standard extension for scalar cryptography | 1.0.1 | Ratified | 49[53] |
| H | Standard extension for hypervisor | 1.0 | Ratified | 15 |
| S | Standard extension for supervisor-level instructions | 1.12 | Ratified | 4 |
| Zam | Misaligned atomics | 0.1 | Open | |
| Zihintpause | Pause hint | 2.0 | Ratified | |
| Zihintntl | Non-temporal locality hints | 0.3 | Ratified | |
| Zfa | Additional floating-point instructions | 1.0 | Ratified | |
| Zfh | Half-precision floating-point | 1.0 | Ratified | |
| Zfhmin | Minimal half-precision floating-point | 1.0 | Ratified | |
| Zfinx | Single-precision floating-point in integer register | 1.0 | Ratified | |
| Zdinx | Double-precision floating-point in integer register | 1.0 | Ratified | |
| Zhinx | Half-precision floating-point in integer register | 1.0 | Ratified | |
| Zhinxmin | Minimal half-precision floating-point in integer register | 1.0 | Ratified | |
| Zmmul | Multiplication subset of the M extension | 1.0 | Ratified | |
| Ztso | Total store ordering | 1.0 | Ratified | |
| Format | Bit | |||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 31 | 30 | 29 | 28 | 27 | 26 | 25 | 24 | 23 | 22 | 21 | 20 | 19 | 18 | 17 | 16 | 15 | 14 | 13 | 12 | 11 | 10 | 9 | 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | |
| Register/register | funct7 | rs2 | rs1 | funct3 | rd | opcode | ||||||||||||||||||||||||||
| Immediate | imm[11:0] | rs1 | funct3 | rd | opcode | |||||||||||||||||||||||||||
| Store | imm[11:5] | rs2 | rs1 | funct3 | imm[4:0] | opcode | ||||||||||||||||||||||||||
| Branch | [12] | imm[10:5] | rs2 | rs1 | funct3 | imm[4:1] | [11] | opcode | ||||||||||||||||||||||||
| Upper immediate | imm[31:12] | rd | opcode | |||||||||||||||||||||||||||||
| Jump | [20] | imm[10:1] | [11] | imm[19:12] | rd | opcode | ||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||
To name the combinations of functions that may be implemented, a nomenclature is defined to specify them in Chapter 27 of the current ratified Unprivileged ISA Specification. The instruction set base is specified first, coding for RISC-V, the register bit-width, and the variant; e.g.,RV64I orRV32E. Then follows letters specifying implemented extensions, in the order of the above table. Each letter may be followed by a major optionally followed by "p" and a minor option number. It defaults to 0 if a minor version number is absent, and 1.0 if all of a version number is absent. ThusRV64IMAFD may be written asRV64I1p0M1p0A1p0F1p0D1p0 or more simply asRV64I1M1A1F1D1. Underscores may be used between extensions for readability, for exampleRV32I2_M2_A2.
The base, extended integer & floating-point calculations, with synchronization primitives for multi-core computing, are considered to be necessary for general-purpose computing, and thus we have the shorthand, "G".
A small 32-bit computer for an embedded system might beRV32EC. A large 64-bit computer might beRV64GC; i.e.,RV64IMAFDCZicsr_Zifencei.
With the growth in the number of extensions, the standard now provides for extensions to be named by a single "Z" followed by an alphabetical name and an optional version number. For example,Zifencei names the instruction-fetch extension.Zifencei2 andZifencei2p0 name version 2.0 of the same. The first letter following the "Z" by convention indicates the most closely related alphabetical extension category,IMAFDQLCBJTPVN. Thus the Zam extension for misaligned atomics relates to the "A" standard extension. Unlike single character extensions, Z extensions must be separated by underscores, grouped by category and then alphabetically within each category. For example,Zicsr_Zifencei_Zam.
Extensions specific to supervisor privilege level are named in the same way using "S" for prefix. Extensions specific to hypervisor level are named using "H" for prefix. Machine level extensions are prefixed with the three letters "Zxm". Supervisor, hypervisor and machine level instruction set extensions are named after less privileged extensions.
RISC-V developers may create their own non-standard instruction set extensions. These follow the "Z" naming convention, but with "X" as the prefix. They should be specified after all standard extensions, and if multiple non-standard extensions are listed, they should be listed alphabetically.
Profiles and platforms for standard ISA choice lists are under discussion.
This flexibility can be used to highly optimize a specialized design by including only the exact set of ISA features required for an application, but the same flexibility also leads to a combinatorial explosion in possible ISA choices. Profiles specify a much smaller common set of ISA choices that capture the most value for most users, and which thereby enable the software community to focus resources on building a rich software ecosystem.
— [54]
The platform specification defines a set of platforms that specify requirements for interoperability between software and hardware. The Platform Policy defines the various terms used in this platform specification. The platform policy also provides the needed detail regarding the scope, coverage, naming, versioning, structure, life cycle and compatibility claims for the platform specification.[58]
As a RISC architecture, the RISC-V ISA is aload–store architecture. Its floating-point instructions useIEEE 754 floating-point. Notable features of the RISC-V ISA include: instruction bit field locations chosen to simplify the use ofmultiplexers in a CPU,[2]: 17 a design that is architecturally neutral,[dubious –discuss] and a fixed location for the sign bit ofimmediate values to speed upsign extension.[2]: 17
The instruction set is designed for a wide range of uses. The base instruction set has a fixed length of32-bit naturally aligned instructions, and the ISA supports variable length extensions where each instruction can be any number of16-bit parcels in length.[2]: 7–10 Extensions support smallembedded systems,personal computers,supercomputers with vector processors, and warehouse-scaleparallel computers.
The instruction set specification defines 32-bit and64-bitaddress space variants. The specification includes a description of a128-bit flat address space variant, as an extrapolation of 32- and 64-bit variants, but the 128-bit ISA remains "not frozen" intentionally, because as of 2023[update], there is still little practical experience with such large memory systems.[2]: 41
Unlike other academic designs which are typically optimized only for simplicity of exposition, the designers intended that the RISC-V instruction set be usable for practical computers. As of June 2019, version 2.2 of the user-space ISA[59] and version 1.11 of theprivileged ISA[3] arefrozen, permitting software and hardware development to proceed. The user-space ISA, now renamed the Unprivileged ISA, was updated, ratified and frozen as version 20191213.[2] An external debug specification is available as a draft, version 0.13.2.[60]
| Register name | Symbolic name | Description | Saved by |
|---|---|---|---|
| 32integer registers | |||
| x0 | zero | Always zero | |
| x1 | ra | Return address | Caller |
| x2 | sp | Stack pointer | Callee |
| x3 | gp | Global pointer | |
| x4 | tp | Thread pointer | |
| x5 | t0 | Temporary / alternate return address | Caller |
| x6–7 | t1–2 | Temporaries | Caller |
| x8 | s0/fp | Saved register /frame pointer | Callee |
| x9 | s1 | Saved register | Callee |
| x10–11 | a0–1 | Function arguments / return values | Caller |
| x12–17 | a2–7 | Function arguments | Caller |
| x18–27 | s2–11 | Saved registers | Callee |
| x28–31 | t3–6 | Temporaries | Caller |
| 32floating-point extension registers | |||
| f0–7 | ft0–7 | Floating-point temporaries | Caller |
| f8–9 | fs0–1 | Floating-point saved registers | Callee |
| f10–11 | fa0–1 | Floating-point arguments/return values | Caller |
| f12–17 | fa2–7 | Floating-point arguments | Caller |
| f18–27 | fs2–11 | Floating-point saved registers | Callee |
| f28–31 | ft8–11 | Floating-point temporaries | Caller |
RISC-V has 32integer registers (or 16 in the embedded variant),[2]: 13, 33 and when the floating-point extension is implemented, an additional 32floating-point registers.[2]: 63 Except for memory access instructions, instructions address onlyregisters.
The first integer register is azero register, and the remainder are general-purpose registers. A store to the zero register has no effect, and a read always provides 0. Using the zero register as a placeholder makes for a simpler instruction set.
Control and status registers exist, but user-mode programs can access only those used for performance measurement and floating-point management.
No instructions exist to save and restore multiple registers. Those were thought to be needless, too complex, and perhaps too slow.[49]
Like many RISC designs, RISC-V is aload–store architecture: instructions address only registers, with load and store instructions conveying data to and from memory.
Most load and store instructions include a 12-bit offset and two register identifiers. One register is the base register. The other register is the destination (for a load) or the source (for a store).
The offset is added to a base register to get the address.[2]: 24 Forming the address as a base register plus offset allows single instructions to access data structures. For example, if the base register points to the top of a stack, single instructions can access a subroutine's local variables in the stack. Likewise the load and store instructions can access a record-style structure or a memory-mapped I/O device. Using the constant zero register as a base address allows single instructions to access memory near address zero.
Memory is addressed as 8-bit bytes, with instructions being inlittle-endian order,[2]: 9–10 and with data being in the byte order defined by the execution environment interface in which code is running.[2]: 3, 9–10, 24 Words, up to the register size, can be accessed with the load and store instructions.
RISC-V was originally specified as little-endian to resemble other familiar, successful computers, for example,x86.[2]: 9–10 This also reduces a CPU's complexity and costs slightly less because it reads all sizes of words in the same order. For example, the RISC-V instruction set decodes starting at the lowest-addressed byte of the instruction. Big-endian and bi-endian variants were defined for support of legacy code bases that assume big-endianness.[2]: 9–10 The privileged ISA defines bits in themstatus andmstatush registers that indicate and, optionally, control whether M-mode, S-mode, and U-mode memory accesses other than instruction fetches are little-endian or big-endian; those bits may be read-only, in which case the endianness of the implementation is hardwired, or may be writable.[3]: 23–24
An execution environment interface may allow accessed memory addresses not to be aligned to their word width, but accesses to aligned addresses may be faster; for example, simple CPUs may implement unaligned accesses with slow software emulation driven from an alignment failureinterrupt.[2]: 3, 24–25
Like many RISC instruction sets (and somecomplex instruction set computer (CISC) instruction sets, such asx86 andIBM System/360 and its successors throughz/Architecture), RISC-V lacks address-modes that write back to the registers. For example, it does not auto-increment.[2]: 24
RISC-V manages memory systems that are shared between CPUs orthreads by ensuring a thread of execution always sees its memory operations in the programmed order. But between threads and I/O devices, RISC-V is simplified: it doesn't guarantee the order of memory operations, except by specific instructions, such asfence.
Afence instruction guarantees that the results of predecessor operations are visible to successor operations of other threads or I/O devices.fence can guarantee the order of combinations of both memory and memory-mapped I/O operations. E.g. it can separate memory read and write operations, without affecting I/O operations. Or, if a system can operate I/O devices in parallel with memory,fence doesn't force them to wait for each other. One CPU with one thread may decodefence asnop.
Some RISC CPUs (such asMIPS,PowerPC,DLX, and Berkeley's RISC-I) place 16 bits of offset in the loads and stores. They set the upper 16 bits by aload upper word instruction. This permits upper-halfword values to be set easily, without shifting bits. However, most use of the upper half-word instruction makes 32-bit constants, like addresses. RISC-V uses aSPARC-like combination of 12-bit offsets and 20-bitset upper instructions. The smaller 12-bit offset helps compact, 32-bit load and store instructions select two of 32 registers yet still have enough bits to support RISC-V's variable-length instruction coding.[2]: 16
RISC-V handles 32-bit constants and addresses with instructions that set the upper 20 bits of a 32-bit register. Load upper immediatelui loads 20 bits into bits 31 through 12. Then a second instruction such asaddi can set the bottom 12 bits. Small numbers or addresses can be formed by using the zero register instead oflui.
This method is extended to permitposition-independent code by adding an instruction,auipc that generates 20 upper address bits by adding an offset to the program counter and storing the result into a base register. This permits a program to generate 32-bit addresses that are relative to the program counter.
The base register can often be used as-is with the 12-bit offsets of the loads and stores. If needed,addi can set the lower 12 bits of a register. In 64-bit and 128-bit ISAs,lui andauipc sign-extend the result to get the larger address.[2]: 37
Some fast CPUs may interpret combinations of instructions as singlefused instructions.lui orauipc are good candidates to fuse withjalr,addi, loads or stores.
RISC-V's subroutine calljal (jump and link) places its return address in a register. This is faster in many computer designs, because it saves a memory access compared to systems that push a return address directly on a stack in memory.jal has a 20-bit signed (two's complement) offset. The offset is multiplied by 2, then added to the PC (program counter) to generate a relative address to a 32-bit instruction. If the resulting address is not 32-bit aligned (i.e. evenly divisible by 4), the CPU may force anexception.[2]: 20–23, Section 2.5
RISC-V CPUs jump to calculated addresses using ajump and link-register,jalr instruction.jalr is similar tojal, but gets its destination address by adding a 12-bit offset to a base register. (In contrast,jal adds a larger 20-bit offset to the PC.)
jalr's bit format is like the register-relative loads and stores. Like them,jalr can be used with the instructions that set the upper 20 bits of a base register to make 32-bit branches, either to an absolute address (usinglui) or a PC-relative one (usingauipc for position-independent code). (Using a constant zero base address allows single-instruction calls to a small (the offset), fixed positive or negative address.)
RISC-V recyclesjal andjalr to get unconditional 20-bit PC-relative jumps and unconditional register-based 12-bit jumps. Jumps just make the linkage register 0 so that no return address is saved.[2]: 20–23, Section 2.5
RISC-V also recyclesjalr to return from a subroutine: To do this,jalr's base register is set to be the linkage register saved byjal orjalr.jalr's offset is zero and the linkage register is zero, so that there is no offset, and no return address is saved.
Like many RISC designs, in a subroutine call, a RISC-V compiler must use individual instructions to save registers to the stack at the start, and then restore these from the stack on exit. RISC-V has nosave multiple orrestore multiple register instructions. These were thought to make the CPU too complex, and possibly slow.[61] This can take more code space. Designers planned to reduce code size with library routines to save and restore registers.[62]
RISC-V has nocondition code register orcarry bit. The designers believed that condition codes make fast CPUs more complex by forcing interactions between instructions in different stages of execution. This choice makes multiple-precision arithmetic more complex. Also, a few numerical tasks need more energy. As a result,predication (the conditional execution of instructions) is not supported. The designers claim that very fast, out-of-order CPU designs do predication anyway, by doing the comparison branch and conditional code in parallel, then discarding the unused path's effects. They also claim that even in simpler CPUs, predication is less valuable thanbranch prediction, which can prevent most stalls associated with conditional branches. Code without predication is larger, with more branches, but they also claim that acompressed instruction set (such as RISC-V's setC) solves that problem in most cases.[49][failed verification]
Instead, RISC-V has short branches that perform comparisons: equal, not-equal, less-than, unsigned less-than, greater-than or equal and unsigned greater-than or equal. Ten comparison-branch operations are implemented with only six instructions, by reversing the order of operands in theassembler. For example,branch if greater than can be done byless-than with a reversed order of operands.[2]: 20–23, Section 2.5
The comparing branches have a twelve-bit signed range, and jump relative to the PC.[2]: 20–23, Section 2.5
Unlike some RISC architectures, RISC-V does not include abranch delay slot, a position after a branch instruction that can be filled with an instruction that is executed whether or not the branch is taken.[2]: 20–23, Section 2.5 RISC-V omits a branch delay slot because it complicates multicycle CPUs, superscalar CPUs, and long pipelines. Dynamicbranch predictors have succeeded well enough to reduce the need for delayed branches.[49]
On the first encounter with a branch, RISC-V CPUs should assume that a negative relative branch (i.e. the sign bit of the offset is "1") will be taken.[2]: 20–23, Section 2.5 This assumes that a backward branch is a loop, and provides a default direction so that simple pipelined CPUs can fill their pipeline of instructions. Other than this, RISC-V does not requirebranch prediction, but core implementations are allowed to add it. RV32I reserves a "HINT" instruction space that presently does not contain any hints on branches;[2]: 28–29, Section 2.9 RV64I does the same.[2]: 38–39, Section 5.4
RISC-V segregates math into a minimal set ofinteger instructions (setI) withadd, subtract, shift, bitwise logic and comparing-branches. These can simulate most of the other RISC-V instruction sets with software. (The atomic instructions are a notable exception.) RISC-V integer instructions lack thecount leading zero and bit-field operations normally used to speed software floating-point in a pure-integer processor, However, while nominally in the bit manipulation extension, the ratified Zbb, Zba and Zbs extensions contain further integer instructions including a count leading zero instruction.
The integer multiplication instructions (setM) include signed and unsigned multiply and divide. Double-precision integer multiplies and divides are included, as multiplies and divides that produce thehigh word of the result. The ISA document recommends that implementors of CPUs and compilersfuse a standardized sequence of high and low multiply and divide instructions to one operation if possible.[2]: 43–45
Thefloating-point instructions (setF) include single-precision arithmetic and also comparison-branches similar to the integer arithmetic. It requires an additional set of 32 floating-point registers. These are separate from the integer registers. The double-precision floating point instructions (setD) generally assume that the floating-point registers are 64-bit (i.e., double-width), and theF subset is coordinated with theD set. A quad-precision 128-bit floating-point ISA (Q) is also defined.[2]: 63–82 RISC-V computers without floating-point can use a floating-point software library.
RISC-V does not causeexceptions on arithmetic errors, includingoverflow,[2]: 17–20 underflow, subnormal, and divide by zero.[2]: 44–45 Instead, both integer and floating-point arithmetic produce reasonable default values, and floating-point instructions set status bits.[2]: 66 Divide-by-zero can be discovered by one branch after the division.[2]: 44–45 The status bits can be tested by an operating system or periodic interrupt.
RISC-V supports computers that share memory between multiple CPUs andthreads. RISC-V's standard memory consistency model isrelease consistency. That is, loads and stores may generally be reordered, but some loads may be designated asacquire operations which must precede later memory accesses, and some stores may be designated asrelease operations which must follow earlier memory accesses.[2]: 83–94
The base instruction set includes minimal support in the form of afence instruction to enforce memory ordering.[2]: 26–27 Although this is sufficient (fence r, rw providesacquire andfence rw, w providesrelease), combined operations can be more efficient.[2]: Chapter 8
The atomic memory operation extension supports two types of atomic memory operations for release consistency. First, it provides general purposeload-reservedlr andstore-conditionalsc instructions.lr performs a load, and tries to reserve that address for its thread. A later store-conditionalsc to the reserved address will be performed only if the reservation is not broken by an intervening store from another source. If the store succeeds, a zero is placed in a register. If it failed, a non-zero value indicates that software needs to retry the operation. In either case, the reservation is released.[2]: Chapter 8
The second group of atomic instructions performread-modify-write sequences: a load (which is optionally a load-acquire) to a destination register, then an operation between the loaded value and a source register, then a store of the result (which may optionally be a store-release). Making the memory barriers optional permits combining the operations. The optional operations are enabled byacquire andrelease bits which are present in every atomic instruction. RISC-V defines nine possible operations: swap (use source register value directly); add; bitwise and, or, and exclusive-or; and signed and unsigned minimum and maximum.[2]: Chapter 8
A system design may optimize these combined operations more thanlr andsc. For example, if the destination register for a swap is the constant zero, the load may be skipped. If the value stored is unmodified since the load, the store may be skipped.[59]: 44
TheIBM System/370 and its successors includingz/Architecture, andx86, both implement acompare-and-swap (cas) instruction, which tests and conditionally updates a location in memory: if the location contains an expected old value,cas replaces it with a given new value; it then returns an indication of whether it made the change. However, a simple load-type instruction is usually performed before thecas to fetch the old value. The classic problem is that if a thread reads (loads) a valueA, calculates a new valueC, and then uses (cas) to replaceA withC, it has no way to know whether concurrent activity in another thread has replacedA with some other valueB and then restored theA in between. In some algorithms (e.g., ones in which the values in memory are pointers to dynamically allocated blocks), thisABA problem can lead to incorrect results. The most common solution employs adouble-widecas instruction to update both the pointer and an adjacent counter; unfortunately, such an instruction requires a special instruction format to specify multiple registers, performs several reads and writes, and can have complex bus operation.[2]: 48–49
Thelr/sc alternative is more efficient. It usually requires only one memory load, and minimizing slow memory operations is desirable. It's also exact: it controls all accesses to the memory cell, rather than just assuring a bit pattern. However, unlikecas, it can permitlivelock, in which two or more threads repeatedly cause each other's instructions to fail. RISC-V guarantees forward progress (no livelock) if the code follows rules on the timing and sequence of instructions: 1) It must use only theI subset. 2) To prevent repetitive cache misses, the code (including the retry loop) must occupy no more than 16 consecutive instructions. 3) It must include no system or fence instructions, or taken backward branches between thelr andsc. 4) The backward branch to the retry loop must be to the original sequence.[2]: 48–49
The specification gives an example of how to use the read-modify-write atomic instructions to lock a data structure.[2]: 54
The standard RISC-V ISA specifies that all instructions are 32 bits. This makes for a particularly simple implementation, but like other RISC processors with 32-bit instruction encoding, results in larger code size than in instruction sets with variable-length instructions.[2]: 99 [61]
To compensate, RISC-V's32-bit instructions are actually 30 bits;3⁄4 of theopcode space is reserved for an optional (but recommended) variable-lengthcompressed instruction set, RVC, that includes 16-bit instructions. As inARM Thumb andMIPS16, the compressed instructions are simply alternative encodings for a subset of the larger instructions. Unlike the ARM or MIPS compressed sets, space was reserved from the start so there is no separate operating mode. Standard and compressed instructions may be intermixed freely.[2]: 97 [61] (Extension letter isC.)[2]: 97
Because (like Thumb-1 and MIPS16) the compressed instructions are simply alternate encodings (aliases) for a selected subset of larger instructions, the compression can be implemented in the assembler, and it is not essential for the compiler to even know about it.
A prototype of RVC was tested in 2011.[61] The prototype code was 20% smaller than anx86 PC andMIPS compressed code, and 2% larger than ARMThumb-2 code.[61] It also substantially reduced both the needed cache memory and the estimated power use of the memory system.[61]
The researcher intended to reduce the code's binary size for small computers, especiallyembedded computer systems. The prototype included 33 of the most frequently used instructions, recoded as compact 16-bit formats using operation codes previously reserved for the compressed set.[61] The compression was done in theassembler, with no changes to the compiler. Compressed instructions omitted fields that are often zero, used small immediate values or accessed subsets (16 or 8) of the registers.addi is very common and often compressible.[61]
Much of the difference in size compared to ARM's Thumb set occurred because RISC-V, and the prototype, have no instructions to save and restore multiple registers. Instead, the compiler generated conventional instructions that access the stack. The prototype RVC assembler then often converted these to compressed forms that were half the size. However, this still took more code space than the ARM instructions that save and restore multiple registers. The researcher proposed to modify the compiler to call library routines to save and restore registers. These routines would tend to remain in a code cache and thus run fast, though probably not as fast as a save-multiple instruction.[61]
Standard RVC requires occasional use of 32-bit instructions. Several nonstandard RVC proposals are complete, requiring no 32-bit instructions, and are said to have higher densities than standard RVC.[63][64] Another proposal builds on these, and claims to use less coding range as well.[65]
An instruction set for the smallestembedded CPUs (set E) is reduced in other ways: Only 16 of the 32 integer registers are supported.[2]: Chapter 4 All current extensions may be used; a floating-point extension to use the integer registers for floating-point values is being considered. The privileged instruction set supports only machine mode, user mode and memory schemes that use base-and-bound address relocation.[3]
Discussion has occurred for a microcontroller profile for RISC-V, to ease development of deeply embedded systems. It centers on faster, simple C-language support for interrupts, simplified security modes and a simplifiedPOSIX application binary interface.[66]
Correspondents have also proposed smaller, non-standard, 16-bitRV16E ISAs: Several serious proposals would use the 16-bitC instructions with 8 × 16-bit registers.[64][63] An April fools' joke proposed a very practical arrangement: Utilize 16 × 16-bit integer registers, with the standardEIMC ISAs (including 32-bit instructions.) The joke was to usebank switching when a 32-bit CPU would be clearly superior with the larger address space.[67]
RISC-V's ISA includes a separateprivileged instruction set specification, which mostly describes three privilege levels plus an orthogonal hypervisor mode. As of December 2021[update], version 1.12 is ratified by RISC-V International.[3]
Version 1.12 of the specification supports several types of computer systems:
These correspond roughly to systems with up to fourrings of privilege and security, at most: machine, hypervisor, supervisor and user. Each layer also is expected to have a thin layer of standardized supporting software that communicates to a more-privileged layer, or hardware.[3]
The ISA also includes a hypervisor mode that isorthogonal to the user and supervisor modes.[68] The basic feature is a configuration bit that either permits supervisor-level code to access hypervisor registers, or causes an interrupt on accesses. This bit lets supervisor mode directly handle the hardware needed by a hypervisor. This simplifies the implementation of hypervisors that are hosted by an operating system. This is a popular mode to run warehouse-scale computers. To support non-hosted hypervisors, the bit can cause these accesses to interrupt to a hypervisor. The design also simplifies nesting of hypervisors, in which a hypervisor runs under a hypervisor, and if necessary it lets the kernel use hypervisor features within its own kernel code. As a result, the hypervisor form of the ISA supports five modes: machine, supervisor, user, supervisor-under-hypervisor and user-under-supervisor.
The privileged instruction set specification explicitly defineshardwarethreads, orharts. Multiple hardware threads are a common practice in more-capable computers. When one thread is stalled, waiting for memory, others can often proceed. Hardware threads can help make better use of the large number of registers and execution units in fast out-of-order CPUs. Finally, hardware threads can be a simple, powerful way to handleinterrupts: No saving or restoring of registers is required, simply executing a different hardware thread. However, the only hardware thread required in a RISC-V computer is thread zero.[3]
Interrupts and exceptions are handled together. Exceptions are caused by instruction execution including illegal instructions and system calls, while interrupts are caused by external events. The existing control and status register definitions support RISC-V's error and memory exceptions, and a small number of interrupts, typically via an "advanced core local interruptor" (ACLINT).[69] For systems with more interrupts, the specification also defines aplatform-level interrupt controller (PLIC) to coordinate large number of interrupts among multiple processors. Interrupts always start at the highest-privileged machine level, and the control registers of each level have explicitforwarding bits to route interrupts to less-privileged code. For example, the hypervisor need not include software that executes on each interrupt to forward an interrupt to an operating system. Instead, on set-up, it can set bits to forward the interrupt.[3]
Several memory systems are supported in the specification. Physical-only is suited to the simplest embedded systems. There are also fourUNIX-stylevirtual memory systems for memory cached in mass-storage systems. The virtual memory systems supportMMU with four sizes, with addresses sized 32, 39, 48 and 57 bits. All virtual memory systems support 4 KiB pages, multilevel page-table trees and use very similar algorithms to walk the page table trees. All are designed for either hardware or software page-table walking. To optionally reduce the cost of page table walks, super-sized pages may be leaf pages in higher levels of a system's page table tree. SV32 is only supported on 32-bit implementations, has a two-layer page table tree and supports 4 MiB superpages. SV39 has a three level page table, and supports 2 MiB superpages and 1 GiB gigapages. SV48 is required to support SV39. It also has a 4-level page table and supports 2 MiB superpages, 1 GiB gigapages, and 512 GiB terapages. SV57 has a 5-level page table and supports 2 MiB superpages, 1 GiB gigapages, 512 GiB terapages and 256 TiB petapages. Superpages are aligned on the page boundaries for the next-lowest size of page.[3]
Some bit-manipulation ISA extensions were ratified in November 2021 (Zba, Zbb, Zbc, Zbs).[51] The Zba, Zbb, and Zbs extensions are arguably extensions of the standard I integer instructions: Zba contains instructions to speed up the computation of the addresses of array elements in arrays of datatypes of size 2, 4, or 8 bytes (sh1add, sh2add, sh3add), and for 64 (and 128) bit processors when indexed with unsigned integers (add.uw, sh1add.uw, sh2add.uw, sh3add.uw and slli.uw). The Zbb instructions contains operations to count leading, trailing 0 bits or all 1 bits in a full and 32 word operations (clz, clzw, ctz, ctzw, cpop, cpopw), byte order reversion (rev8), logical instructions with negation of the second input (andn,orn, xnor), sign and zero extension (sext.b, sext.h, zext.h) that could not be provided as special cases of other instructions (andi, addiw, add.wu), min and max of (signed and unsigned) integers, (left and right) rotation of bits in a register and 32-bit words (rori,roriw, ror, rorw, rol, rolw), and a byte wise "or combine" operation which allows detection of a zero byte in a full register, useful for handling C-style null terminated strings functions. The Zbs extension allows setting, getting, clearing, and toggling individual bits in a register by their index (bseti, bset, bexti, bext, bclri, bclr, binvi,binv).
The Zbc extension has instructions for "carryless multiplication", which does the multiplication ofpolynomials over theGalois field GF(2) (clmul, clmulh, clmulr). These are useful for cryptography and CRC checks of data integrity.
Done well, a more specialised bit-manipulation subset can aid cryptographic, graphic, and mathematical operations. Further instructions that have been discussed include instructions to shift in ones, a generalized bit-reverse, shuffle and crossbar permutations, bit-field place, extract and deposit pack two words, bytes or halfwords in one register, CRC instructions, bit-matrix operations (RV64 only), conditional mix, conditional move, funnel shifts. The criteria for inclusion documented in the draft were compliant with RISC-V philosophies and ISA formats, substantial improvements in code density or speed (i.e., at least a 3-for-1 reduction in instructions), and substantial real-world applications, including preexisting compiler support. Version 0.93 of the bit-manipulation extension includes those instructions;[70] some of them are now in version 1.0.1 of the scalar andentropy source instructions cryptography extension.[53]
Packed-SIMD instructions are widely used by commercial CPUs to inexpensively accelerate multimedia and otherdigital signal processing.[49] For simple, cost-reduced RISC-V systems, the base ISA's specification proposed to use the floating-point registers' bits to perform parallel single instruction, multiple data (SIMD) sub-word arithmetic.
In 2017 a vendor published a more detailed proposal to the mailing list, and this can be cited as version 0.1.[71] As of 2019[update], the efficiency of this proposed ISA varies from 2x to 5x a base CPU for a variety of DSP codecs.[72] The proposal lacked instruction formats and a license assignment to RISC-V International, but it was reviewed by the mailing list.[71] Some unpopular parts of this proposal were that it added a condition code, the first in a RISC-V design, linked adjacent registers (also a first), and has a loop counter that can be difficult to implement in some microarchitectures.
The proposedvector-processing instruction set may make the packedSIMD set obsolete. The designers hope to have enough flexibility that a CPU can implement vector instructions in a standard processor's registers. This would enable minimal implementations with similar performance to a multimedia ISA, as above. However, a true vector coprocessor could execute the same code with higher performance.[73]
As of 19 September 2021[update], the vector extension is at version 1.0.[74] It is a conservative, flexible design of a general-purpose mixed-precision vector processor, suitable to executecompute kernels. Code would port easily to CPUs with differing vector lengths, ideally without recompiling.[73]
In contrast, short-vector SIMD extensions are less convenient. These are used inx86, ARM andPA-RISC. In these, a change in word-width forces a change to the instruction set to expand the vector registers (in the case of x86, from 64-bitMMX registers to 128-bitStreaming SIMD Extensions (SSE), to 256-bitAdvanced Vector Extensions (AVX), andAVX-512). The result is a growing instruction set, and a need to port working code to the new instructions.
In the RISC-V vector ISA, rather than fix the vector length in the architecture, instructions (vsetvli,vsetivli, andvsetvl) are available which take a requested size and sets the vector length to the minimum of the hardware limit and the requested size. So, the RISC-V proposal is more like aCray's long-vector design or ARM's Scalable Vector Extension. That is, each vector in up to 32 vectors is the same length.[74]: 25
The application specifies the total vector width it requires, and the processor determines the vector length it can provide with available on-chip resources. This takes the form of an instruction (vsetcfg) with four immediate operands, specifying the number of vector registers of each available width needed. The total must be no more than the addressable limit of 32, but may be less if the application does not require them all. The vector length is limited by the available on-chip storage divided by the number of bytes of storage needed for each entry. (Added hardware limits may also exist, which in turn may permit SIMD-style implementations.)[73]
Outside of vector loops, the application can zero the number of requested vector registers, saving the operating system the work of preserving them oncontext switches.[73]
The vector length is not only architecturally variable, but designed to vary at run time also. To achieve this flexibility, the instruction set is likely to use variable-width data paths and variable-type operations using polymorphic overloading.[73] The plan is that these can reduce the size and complexity of the ISA and compiler.[73]
Recent experimental vector processors with variable-width data paths also show profitable increases in operations per: second (speed), area (lower cost), and watt (longer battery life).[75]
Unlike a typical moderngraphics processing unit, there are no plans to provide special hardware to supportbranch predication. Instead, lower cost compiler-based predication will be used.[73][76]
There is a preliminary specification for RISC-V's hardware-assisteddebugger. The debugger will use a transport system such as Joint Test Action Group (JTAG) or Universal Serial Bus (USB) to access debug registers. A standard hardware debug interface may support either astandardized abstract interface orinstruction feeding.[77][78]
As of January 2017[update], the exact form of theabstract interface remains undefined, but proposals include a memory mapped system with standardized addresses for the registers of debug devices or a command register and a data register accessible to the communication system.[77] Correspondents claim that similar systems are used byFreescale'sbackground debug mode interface (BDM) for some CPUs,ARM,OpenRISC, andAeroflex'sLEON.[77]
Ininstruction feeding, the CPU will process a debug exception to execute individual instructions written to a register. This may be supplemented with a data-passing register and a module to directly access the memory. Instruction feeding lets the debugger access the computer exactly as software would. It also minimizes changes in the CPU, and adapts to many types of CPU. This was said to be especially apt for RISC-V because it is designed explicitly for many types of computers. The data-passing register allows a debugger to write a data-movement loop to RAM, and then execute the loop to move data into or out of the computer at a speed near the maximum speed of the debug system's data channel.[77] Correspondents say that similar systems are used byMIPS TechnologiesMIPS,Intel Quark,Tensilica'sXtensa, and forFreescalePower ISA CPUs'background debug mode interface (BDM).[77]
A vendor proposed a hardware trace subsystem for standardization, donated a conforming design, and initiated a review.[79][80] The proposal is for a hardware module that can trace code execution on most RISC-V CPUs. To reduce the data rate, and permit simpler or less-expensive paths for the trace data, the proposal does not generate trace data that can be calculated from a binary image of the code. It sends only data that indicates "uninferrable" paths through the program, such as which conditional branches are taken. To reduce the data rates, branches that can be calculated, such as unconditional branches, are not traced. The proposed interface between the module and the control unit is a logic signal for each uninferrable type of instruction. Addresses and other data are to be provided in a specialized bus attached to appropriate data sources in a CPU. The data structure sent to an external trace unit is a series of short messages with the needed data. The details of the data channel are intentionally not described in the proposal, because several are likely to make sense.
The RISC-V organization maintains a list of RISC-V CPU and SoC implementations.[81] Due to trade wars and possible sanctions that would prevent China from accessing proprietary ISAs, as of 2023 the country was planning to shift most of its CPU and MCU architectures to RISC-V cores.[82]
In 2023, the European Union was set to provide 270 million euros within a so-called Framework Partnership Agreement (FPA) to a single company that was able and willing to carry out a RISC-V CPU development project aimed at supercomputers, servers, and data centers.[83] The European Union's aim was to become independent from political developments in other countries and to "strengthen its digital sovereignty and set standards, rather than following those of others."[84]
Existing proprietary implementations include:
DeepComputing of Hong Kong announced the release on 13 April 2023 of the "world's first laptop with RISC-V processor"; the notebook, called "ROMA", was delivered to its first customers in August 2023[173] and came pre-installed with the ChineseopenKylin Linux operating system.[174] The device's basic model, available fromAlibaba, was still expensive at roughly US$1500[175] considering it was powered by the not very fast[176] Alibaba (DAMO) CPU "XuanTie C910".
An upgrade in June 2024 doubled the core count to 8 cores and increased the clock speed to 2 GHz (from 1.5 GHz), while dropping the price to US$1,000.[177] The processor used was aSpacemiT SoC K1.[178][179] A collaboration withCanonical[180] meant that the ROMA II came pre-installed with the major international Linux distributionUbuntu.[181]
In 2024, DeepComputing announced a collaboration withFramework Computer to produce amainboard for their Framework Laptop 13.[182][183] As of 4 February 2025, it is ready to ship and mainly targeted at developers. It features a 4-core StarFive JH7110 processor.[184]
A normal problem for a new instruction set is both a lack of CPU designs and of software, which limit its usability and reduce adoption.[25] In addition to already having a large number of CPU hardware designs, RISC-V is also supported by toolchains, operating systems (e.g.Linux),middleware[vague] and design software.
Available RISC-V software tools include aGNU Compiler Collection (GCC) toolchain (withGDB, the debugger), anLLVM toolchain, theOVPsim simulator (and library of RISC-V Fast Processor Models), the Spike simulator, and a simulator inQEMU (RV32GC/RV64GC).JEP 422: Linux/RISC-V Port is already integrated into mainlineOpenJDK repository. Java 21+ Temurin OpenJDK builds for RISC-V are available fromAdoptium.
Operating system support exists for theLinux kernel,FreeBSD,NetBSD, andOpenBSD but the supervisor-mode instructions were unstandardized before version 1.11 of the privileged ISA specification,[3] so this support is provisional. The preliminary FreeBSD port to the RISC-V architecture was upstreamed in February 2016, and shipped in FreeBSD 11.0.[185][130]
Ports of theDebian,[186][11]Fedora,[187] andopenSUSE[188]Linux distributions, and a port ofHaiku,[189] are stabilizing (all only support 64-bit RISC-V, with no plans to support the 32-bit version). In June 2024, Hong Kong company DeepComputing announced the commercial availability of the first RISC-V laptop in the world to run the popular Linux operating systemUbuntu in its standard form ("out of the box").[18] "As RISC-V is becoming a competitive ISA in multiple markets, porting Ubuntu to RISC-V to become the reference OS [operating system] for early adopters was a natural choice," Ubuntu-developerCanonical stated in June 2024.[190]
A port ofDas U-Boot exists.[191] UEFI Spec v2.7 has defined the RISC-V binding and aTianoCore port has been done byHPE engineers[192] and is expected to be upstreamed. A RISC-V boot deep dive was done as part ofopenSUSE Hackweek 20.[193] There is a preliminary port ofthe seL4 microkernel.[194][195] Hex Five released the first Secure IoT Stack for RISC-V withFreeRTOS support.[196] Alsoxv6, a modern reimplementation ofSixth Edition Unix inANSI C used for pedagogical purposes inMIT, was ported. Pharos RTOS has been ported to 64-bit RISC-V[197] (including time and memory protection).Also seeComparison of real-time operating systems.
A simulator exists to run a RISC-V Linux system on aweb browser usingJavaScript.[198][199][200]
QEMU supports running (usingbinary translation) 32- and 64-bit RISC-V systems (e.g. Linux) with many emulated or virtualized devices (serial, parallel, USB, network, storage, real time clock, watchdog, audio), as well as running RISC-V Linux binaries (translating syscalls to the host kernel). It does support multi-core emulation (SMP).[201]
The CREATOR simulator is portable and allows the user to learn various assembly languages of different processors (CREATOR has examples with an implementation of RISC-V and MIPS32 instructions).[202][203][204][205][206]
Several languages have been applied to creating RISC-V IP cores including aScala-based hardware description language,Chisel,[207] which can reduce the designs toVerilog for use in devices, and the CodAL processor description language which has been used in to describe RISC-V processor cores and to generate corresponding HDKs (RTL, testbench andUVM) and SDKs.[208] The RISC-V International Compliance Task Group has a GitHub repository for RV32IMC.[209]
The extensible educational simulator WepSIM implements amicroprogrammed subset of RISC-V instructions (RV32I+M) and allows the execution ofsubroutines on both, at assembly and microprogramming level.[210][211]
{{cite web}}:Missing or empty|title= (help)At ASTC (www.astc-design.com), we have an implementation of RV32EC as a synthesizable IP core intended for small embedded applications, such as smart sensors and IoT.
