RISC-V非特权指令集规范详解

需积分: 10 100 浏览量更新于2024-07-17 收藏 995KB PDF 举报

"RISCv 规范详细介绍了非特权指令集，涵盖了IFMAD标准扩展，支持32位和64位架构，版本为2019年6月8日更新的Base-Ratified版。该文档由Andrew Waterman和Krste Asanović等人编辑，包括来自多个领域的贡献者。" RISC-V（Reduced Instruction Set Computer - Version 5）是一种开放源码的指令集架构（ISA），旨在提供高效、简洁且可扩展的计算平台设计。RISC-V指令集设计的核心理念是简化指令执行，降低复杂性，从而提高性能和能效。非特权ISA（Unprivileged ISA）是指那些不涉及操作系统或特权模式的指令，它们通常用于用户级程序。在RISC-V中，非特权指令集定义了基本的算术、逻辑、控制转移以及内存访问操作，这些操作是所有软件运行的基础。 IFMAD（可能是错误或者缩写不全，因为在RISC-V官方文档中未找到确切的对应内容）可能指的是某些特定的扩展或者特性，但在此没有足够的信息进行详细解释。在RISC-V架构中，通常会有各种扩展来增加新的功能，如向量运算（Vector Extension）、浮点运算（Floating-Point Extension）等。 32位和64位架构支持表示RISC-V可以应用于从嵌入式设备到高性能计算的不同场景。32位（RV32）适用于资源有限的系统，而64位（RV64）则更适合需要大内存地址空间和高性能计算的场合。文档版本“20190608-Base-Ratified”表明这是2019年6月8日最终确定并批准的基础版本，意味着这个版本的指令集已经稳定，可供硬件和软件开发者使用。编辑者Andrew Waterman和Krste Asanović是SiFive公司的成员，SiFive是一家专注于RISC-V架构的公司。其他贡献者列表显示了RISC-V规范的发展是由一个多元化的专家团队协作完成的，这有助于确保规范的广泛接受和兼容性。 RISC-V的非特权指令集规范是理解和开发基于RISC-V架构的处理器和软件的关键文档。它详细规定了处理器如何执行基本操作，为硬件设计者和软件开发者提供了清晰的接口。随着RISC-V生态系统的不断扩展，这种标准化的规范对于推动开源硬件和软件的发展至关重要。

xiv Volume I: RISC-V Unprivileged ISA V20190608-Base-Ratiﬁed

Chapter 1

Introduction

RISC-V (pronounced “risk-ﬁve”) is a new instruction-set architecture (ISA) that was originally

designed to support computer architecture research and education, but which we now hope will

also become a standard free and open architecture for industry implementations. Our goals in

deﬁning RISC-V include:

• A completely open ISA that is freely available to academia and industry.

• A real ISA suitable for direct native hardware implementation, not just simulation or binary

translation.

• An ISA that avoids “over-architecting” for a particular microarchitecture style (e.g., mi-

crocoded, in-order, decoupled, out-of-order) or implementation technology (e.g., full-custom,

ASIC, FPGA), but which allows eﬃcient implementation in any of these.

• An ISA separated into a small base integer ISA, usable by itself as a base for customized

accelerators or for educational purposes, and optional standard extensions, to support general-

purpose software development.

• Support for the revised 2008 IEEE-754 ﬂoating-point standard [7].

• An ISA supporting extensive ISA extensions and specialized variants.

• Both 32-bit and 64-bit address space variants for applications, operating system kernels, and

hardware implementations.

• An ISA with support for highly-parallel multicore or manycore implementations, including

heterogeneous multiprocessors.

• Optional variable-length instructions to both expand available instruction encoding space and

to support an optional dense instruction encoding for improved performance, static code size,

and energy eﬃciency.

• A fully virtualizable ISA to ease hypervisor development.

• An ISA that simpliﬁes experiments with new privileged architecture designs.

Commentary on our design decisions is formatted as in this paragraph. This non-normative text

can be skipped if the reader is only interested in the speciﬁcation itself.

The name RISC-V was chosen to represent the ﬁfth major RISC ISA design from UC Berkeley

(RISC-I [15], RISC-II [8], SOAR [21], and SPUR [11] were the ﬁrst four). We also pun on the

use of the Roman numeral “V” to signify “variations” and “vectors”, as support for a range of

2 Volume I: RISC-V Unprivileged ISA V20190608-Base-Ratiﬁed

architecture research, including various data-parallel accelerators, is an explicit goal of the ISA

design.

The RISC-V ISA is deﬁned avoiding implementation details as much as possible (although com-

mentary is included on implementation-driven decisions) and should be read as the software-visible

interface to a wide variety of implementations rather than as the design of a particular hardware

artifact. The RISC-V manual is structured in two volumes. This volume covers the design of

the base unprivileged instructions, including optional unprivileged ISA extensions. Unprivileged

instructions are those that are generally usable in all privilege modes in all privileged architectures,

though behavior might vary depending on privilege mode and privilege architecture. The second

volume provides the design of the ﬁrst (“classic”) privileged architecture. The manuals use IEC

80000-13:2008 conventions, with a byte of 8 bits.

In the unprivileged ISA design, we tried to remove any dependence on particular microarchi-

tectural features, such as cache line size, or on privileged architecture details, such as page

translation. This is both for simplicity and to allow maximum ﬂexibility for alternative microar-

chitectures or alternative privileged architectures.

1.1 RISC-V Hardware Platform Terminology

A RISC-V hardware platform can contain one or more RISC-V-compatible processing cores to-

gether with other non-RISC-V-compatible cores, ﬁxed-function accelerators, various physical mem-

ory structures, I/O devices, and an interconnect structure to allow the components to communicate.

A component is termed a core if it contains an independent instruction fetch unit. A RISC-V-

compatible core might support multiple RISC-V-compatible hardware threads, or harts, through

multithreading.

A RISC-V core might have additional specialized instruction-set extensions or an added coprocessor.

We use the term coprocessor to refer to a unit that is attached to a RISC-V core and is mostly

sequenced by a RISC-V instruction stream, but which contains additional architectural state and

instruction-set extensions, and possibly some limited autonomy relative to the primary RISC-V

instruction stream.

We use the term accelerator to refer to either a non-programmable ﬁxed-function unit or a core that

can operate autonomously but is specialized for certain tasks. In RISC-V systems, we expect many

programmable accelerators will be RISC-V-based cores with specialized instruction-set extensions

and/or customized coprocessors. An important class of RISC-V accelerators are I/O accelerators,

which oﬄoad I/O processing tasks from the main application cores.

The system-level organization of a RISC-V hardware platform can range from a single-core micro-

controller to a many-thousand-node cluster of shared-memory manycore server nodes. Even small

systems-on-a-chip might be structured as a hierarchy of multicomputers and/or multiprocessors to

modularize development eﬀort or to provide secure isolation between subsystems.

Volume I: RISC-V Unprivileged ISA V20190608-Base-Ratiﬁed 3

1.2 RISC-V Software Execution Environments and Harts

The behavior of a RISC-V program depends on the execution environment in which it runs. A

RISC-V execution environment interface (EEI) deﬁnes the initial state of the program, the number

and type of harts in the environment including the privilege modes supported by the harts, the

accessibility and attributes of memory and I/O regions, the behavior of all legal instructions exe-

cuted on each hart (i.e., the ISA is one component of the EEI), and the handling of any interrupts

or exceptions raised during execution including environment calls. Examples of EEIs include the

Linux application binary interface (ABI), or the RISC-V supervisor binary interface (SBI). The

implementation of a RISC-V execution environment can be pure hardware, pure software, or a

combination of hardware and software. For example, opcode traps and software emulation can be

used to implement functionality not provided in hardware. Examples of execution environment

implementations include:

• “Bare metal” hardware platforms where harts are directly implemented by physical processor

threads and instructions have full access to the physical address space. The hardware platform

deﬁnes an execution environment that begins at power-on reset.

• RISC-V operating systems that provide multiple user-level execution environments by mul-

tiplexing user-level harts onto available physical processor threads and by controlling access

to memory via virtual memory.

• RISC-V hypervisors that provide multiple supervisor-level execution environments for guest

operating systems.

• RISC-V emulators, such as Spike, QEMU or rv8, which emulate RISC-V harts on an under-

lying x86 system, and which can provide either a user-level or a supervisor-level execution

environment.

A bare hardware platform can be considered to deﬁne an EEI, where the accessible harts, memory,

and other devices populate the environment, and the initial state is that at power-on reset.

Generally, most software is designed to use a more abstract interface to the hardware, as more

abstract EEIs provide greater portability across diﬀerent hardware platforms. Often EEIs are

layered on top of one another, where one higher-level EEI uses another lower-level EEI.

From the perspective of software running in a given execution environment, a hart is a resource that

autonomously fetches and executes RISC-V instructions within that execution environment. In this

respect, a hart behaves like a hardware thread resource even if time-multiplexed onto real hardware

by the execution environment. Some EEIs support the creation and destruction of additional harts,

for example, via environment calls to fork new harts.

The term hart was introduced in the work on Lithe [13, 14] to provide a term to represent an

abstract execution resource as opposed to a software thread programming abstraction.

The important distinction between a hardware thread (hart) and a software thread context

is that the software running inside an execution environment is not responsible for causing

progress of each of its harts; that is the responsibility of the outer execution environment. So

the environment’s harts operate like hardware threads from the perspective of the software inside

the execution environment.

4 Volume I: RISC-V Unprivileged ISA V20190608-Base-Ratiﬁed

An execution environment implementation might time-multiplex a set of guest harts onto

fewer host harts provided by its own execution environment but must do so in a way that guest

harts operate like independent hardware threads. In particular, if there are more guest harts than

host harts then the execution environment must be able to preempt the guest harts and must not

wait indeﬁnitely for guest software on a guest hart to ”yield” control of the guest hart.

1.3 RISC-V ISA Overview

A RISC-V ISA is deﬁned as a base integer ISA, which must be present in any implementation, plus

optional extensions to the base ISA. The base integer ISAs are very similar to that of the early

RISC processors except with no branch delay slots and with support for optional variable-length

instruction encodings. A base is carefully restricted to a minimal set of instructions suﬃcient to

provide a reasonable target for compilers, assemblers, linkers, and operating systems (with addi-

tional privileged operations), and so provides a convenient ISA and software toolchain “skeleton”

around which more customized processor ISAs can be built.

Although it is convenient to speak of the RISC-V ISA, RISC-V is actually a family of related ISAs,

of which there are currently four base ISAs. Each base integer instruction set is characterized by

the width of the integer registers and the corresponding size of the address space and by the number

of integer registers. There are two primary base integer variants, RV32I and RV64I, described in

Chapters 2 and 5, which provide 32-bit or 64-bit address spaces respectively. We use the term

XLEN to refer to the width of an integer register in bits (either 32 or 64). Chapter 4 describes

the RV32E subset variant of the RV32I base instruction set, which has been added to support

small microcontrollers, and which has half the number of integer registers. Chapter 6 sketches a

future RV128I variant of the base integer instruction set supporting a ﬂat 128-bit address space

(XLEN=128). The base integer instruction sets use a two’s-complement representation for signed

integer values.

Although 64-bit address spaces are a requirement for larger systems, we believe 32-bit address

spaces will remain adequate for many embedded and client devices for decades to come and will

be desirable to lower memory traﬃc and energy consumption. In addition, 32-bit address spaces

are suﬃcient for educational purposes. A larger ﬂat 128-bit address space might eventually be

required, so we ensured this could be accommodated within the RISC-V ISA framework.

The four base ISAs in RISC-V are treated as distinct base ISAs. A common question is why

is there not a single ISA, and in particular, why is RV32I not a strict subset of RV64I? Some

earlier ISA designs (SPARC, MIPS) adopted a strict superset policy when increasing address

space size to support running existing 32-bit binaries on new 64-bit hardware.

The main advantage of explicitly separating base ISAs is that each base ISA can be opti-

mized for its needs without requiring to support all the operations needed for other base ISAs.

For example, RV64I can omit instructions and CSRs that are only needed to cope with the nar-

rower registers in RV32I. The RV32I variants can use encoding space otherwise reserved for

instructions only required by wider address-space variants.

The main disadvantage of not treating the design as a single ISA is that it complicates

the hardware needed to emulate one base ISA on another (e.g., RV32I on RV64I). However,

diﬀerences in addressing and illegal instruction traps generally mean some mode switch would

be required in hardware in any case even with full superset instruction encodings, and the diﬀerent

RISC-V base ISAs are similar enough that supporting multiple versions is relatively low cost.

Although some have proposed that the strict superset design would allow legacy 32-bit libraries

剩余235页未读，继续阅读

Rocky

粉丝: 1
资源: 11

RISC-V非特权指令集规范详解

riscv-debug-spec-0.11nov12 Riscv 调试文档

RISC-V debug调试中文说明.pdf

riscv-spec-v2.2.pdf

riscv-spec-20191213.pdf

riscv-spec-v2.1.pdf

riscv-spec-unprivileged-V20191214-draft.pdf

riscv-v-spec-1.0-rc1.pdf

RISCV-spec-v2.1中文版.pdf

riscv-debug-release.pdf

riscv-privileged-20211203.pdf

最新资源