diff options
| -rw-r--r-- | src/a-st-ext.adoc | 14 | ||||
| -rw-r--r-- | src/counters.adoc | 6 | ||||
| -rw-r--r-- | src/d-st-ext.adoc | 4 | ||||
| -rw-r--r-- | src/f-st-ext.adoc | 82 | ||||
| -rw-r--r-- | src/intro.adoc | 100 | ||||
| -rw-r--r-- | src/q-st-ext.adoc | 6 | ||||
| -rw-r--r-- | src/riscv-isa-unpr-conv-review.pdf | bin | 5799991 -> 5782595 bytes | |||
| -rw-r--r-- | src/rv128.adoc | 4 | ||||
| -rw-r--r-- | src/rv32.adoc | 52 | ||||
| -rw-r--r-- | src/rv32e.adoc | 4 | ||||
| -rw-r--r-- | src/rv64.adoc | 7 | ||||
| -rw-r--r-- | src/zicsr.adoc | 9 | ||||
| -rw-r--r-- | src/zifencei.adoc | 4 |
13 files changed, 175 insertions, 117 deletions
diff --git a/src/a-st-ext.adoc b/src/a-st-ext.adoc index 34cdb2c..d7645ca 100644 --- a/src/a-st-ext.adoc +++ b/src/a-st-ext.adoc @@ -177,7 +177,7 @@ successful LR/SC sequences is defined by the Atomicity Axiom in <<rvwmo>>. -[NOTE] +[TIP] ==== The platform should provide a means to determine the size and shape of the reservation set. @@ -224,6 +224,7 @@ instructions are not guaranteed to provide any stronger ordering than those with both bits clear, but may result in lower performance. .Sample code for compare-and-swap function using LR/SC. +[source,cmd] .... # a0 holds address of memory location # a1 holds expected value @@ -312,7 +313,10 @@ loop, or some other device in the system writes to that reservation set. Note that these definitions permit an implementation to fail an SC instruction occasionally for any reason, provided the aforementioned guarantee is not violated. +==== +[TIP] +==== As a consequence of the eventuality guarantee, if some harts in an execution environment are executing constrained LR/SC loops, and no other harts or devices in the execution environment execute an @@ -335,7 +339,10 @@ progress indefinitely. These definitions admit the possibility that SC instructions may spuriously fail for implementation reasons, provided progress is eventually made. +==== +[NOTE] +==== One advantage of CAS is that it guarantees that some hart eventually makes progress, whereas an LR/SC atomic sequence could livelock indefinitely on some systems. To avoid this concern, we added an @@ -382,7 +389,7 @@ Without ordering constraints, these AMOs can be used to implement parallel reduction operations, where typically the return value would be discarded by writing to _x0_. -[NOTE] +[TIP] ==== We provided fetch-and-op style atomic primitives as they scale to highly parallel systems better than LR/SC or CAS. A simple microarchitecture @@ -408,7 +415,7 @@ an AMO makes the sequence sequentially consistent, meaning that it cannot be reordered with earlier or later memory operations from the same hart. -[NOTE] +[TIP] ==== The AMOs were designed to implement the C11 and C++11 memory models efficiently. Although the FENCE R, RW instruction suffices to implement @@ -425,6 +432,7 @@ AMO is marked _rl_ to order the critical section before the lock relinquishment. [[critical]] +.Sample code for mutual exclusion. a0 contains the address of the lock. .... li t0, 1 # Initialize swap value. again: diff --git a/src/counters.adoc b/src/counters.adoc index 38f7ac3..55d7259 100644 --- a/src/counters.adoc +++ b/src/counters.adoc @@ -168,9 +168,9 @@ implementations with a richer set of counters. (((counters, performance))) There is CSR space allocated for 29 additional unprivileged 64-bit -hardware performance counters, _hpmcounter3_–_hpmcounter31_. For RV32, +hardware performance counters, 'hpmcounter3'–'hpmcounter31'. For RV32, the upper 32 bits of these performance counters is accessible via -additional CSRs _hpmcounter3h_–_hpmcounter31h_. These counters count +additional CSRs 'hpmcounter3h'–'hpmcounter31h'. These counters count platform-specific events and are configured via additional privileged registers. The number and width of these additional counters, and the set of events they count is platform-specific. @@ -184,6 +184,6 @@ counted. It would be useful to eventually standardize event settings to count ISA-level metrics, such as the number of floating-point instructions executed for example, and possibly a few common microarchitectural -metrics, such as _L1 instruction cache misses_. +metrics, such as "L1 instruction cache misses". ==== diff --git a/src/d-st-ext.adoc b/src/d-st-ext.adoc index 815f904..abc48f3 100644 --- a/src/d-st-ext.adoc +++ b/src/d-st-ext.adoc @@ -1,7 +1,7 @@ == D Standard Extension for Double-Precision Floating-Point, Version 2.2 This chapter describes the standard double-precision floating-point -instruction-set extension, which is named `D` and adds +instruction-set extension, which is named "D" and adds double-precision floating-point computational instructions compliant with the IEEE 754-2008 arithmetic standard. The D extension depends on the base single-precision instruction subset F. @@ -9,7 +9,7 @@ the base single-precision instruction subset F. === D Register State -The D extension widens the 32 floating-point registers, `f0`–` f31`, to +The D extension widens the 32 floating-point registers, `f0–f31`, to 64 bits (FLEN=64 in <<fprs-d>>. The `f` registers can now hold either 32-bit or 64-bit floating-point values as described below in <<nanboxing>>. diff --git a/src/f-st-ext.adoc b/src/f-st-ext.adoc index 1bd2f9a..88ed2ea 100644 --- a/src/f-st-ext.adoc +++ b/src/f-st-ext.adoc @@ -2,10 +2,10 @@ == F Standard Extension for Single-Precision Floating-Point, Version 2.2 This chapter describes the standard instruction-set extension for -single-precision floating-point, which is named `F` and adds +single-precision floating-point, which is named "F" and adds single-precision floating-point computational instructions compliant with the IEEE 754-2008 arithmetic standard cite:[ieee754-2008]. The F extension depends on -the `Zicsr` extension for control and status register access. +the "Zicsr" extension for control and status register access. === F Register State @@ -36,46 +36,46 @@ floating-point register file state can reduce context-switch overhead. ==== [[fprs]] -.RISC-V standard F exten[sion single-precision floating-point state +.RISC-V standard F extension single-precision floating-point state [col[s="<|^|>"|option[s="header",width="50%",align="center"grid="none"] |=== -<| [small]#FLEN-1#| >| [small]#0# -3+^| [small]#f0# -3+^| [small]#f1# -3+^| [small]#f2# -3+^| [small]#f3# -3+^| [small]#f4# -3+^| [small]#f5# -3+^| [small]#f6# -3+^| [small]#f7# -3+^| [small]#f8# -3+^| [small]#f9# -3+^| [small]#f10# -3+^| [small]#f11# -3+^| [small]#f12# -3+^| [small]#f13# -3+^| [small]#f14# -3+^| [small]#f15# -3+^| [small]#f16# -3+^| [small]#f17# -3+^| [small]#f18# -3+^| [small]#f19# -3+^| [small]#f20# -3+^| [small]#f21# -3+^| [small]#f22# -3+^| [small]#f23# -3+^| [small]#f24# -3+^| [small]#f25# -3+^| [small]#f26# -3+^| [small]#f27# -3+^| [small]#f28# -3+^| [small]#f29# -3+^| [small]#f30# -3+^| [small]#f31# -3+^| [small]#FLEN# -| [small]#31#| >| [small]#0# -3+^| [small]#fcsr# -3+^| [small]#32# +<| [.small]#FLEN-1#| >| [.small]#0# +3+^| [.small]#f0# +3+^| [.small]#f1# +3+^| [.small]#f2# +3+^| [.small]#f3# +3+^| [.small]#f4# +3+^| [.small]#f5# +3+^| [.small]#f6# +3+^| [.small]#f7# +3+^| [.small]#f8# +3+^| [.small]#f9# +3+^| [.small]#f10# +3+^| [.small]#f11# +3+^| [.small]#f12# +3+^| [.small]#f13# +3+^| [.small]#f14# +3+^| [.small]#f15# +3+^| [.small]#f16# +3+^| [.small]#f17# +3+^| [.small]#f18# +3+^| [.small]#f19# +3+^| [.small]#f20# +3+^| [.small]#f21# +3+^| [.small]#f22# +3+^| [.small]#f23# +3+^| [.small]#f24# +3+^| [.small]#f25# +3+^| [.small]#f26# +3+^| [.small]#f27# +3+^| [.small]#f28# +3+^| [.small]#f29# +3+^| [.small]#f30# +3+^| [.small]#f31# +3+^| [.small]#FLEN# +| [.small]#31#| >| [.small]#0# +3+^| [.small]#fcsr# +3+^| [.small]#32# |=== === Floating-Point Control and Status Register @@ -127,7 +127,7 @@ particular, with regard to decoding legal vs. reserved encodings). [[rm]] .Rounding mode encoding. -[cols="^,^,<",options="header",] +[cols="^1,^1,<3",options="header",] |=== |Rounding Mode |Mnemonic |Meaning |000 |RNE |Round to Nearest, ties to Even diff --git a/src/intro.adoc b/src/intro.adoc index c8b381c..2c7c915 100644 --- a/src/intro.adoc +++ b/src/intro.adoc @@ -1,6 +1,6 @@ == Introduction -RISC-V (pronounced "`risk-five`") is a new instruction-set architecture +RISC-V (pronounced "risk-five") 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 @@ -10,7 +10,7 @@ goals in defining RISC-V include: 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 +* An ISA that avoids "over-architecting" for a particular microarchitecture style (e.g., microcoded, in-order, decoupled, out-of-order) or implementation technology (e.g., full-custom, ASIC, FPGA), but which allows efficient implementation in any of these. @@ -43,8 +43,8 @@ in the specification itself. ==== The name RISC-V was chosen to represent the fifth major RISC ISA design from UC Berkeley (RISC-I cite:[riscI-isca1981], RISC-II cite:[Katevenis:1983], SOAR cite:[Ungar:1984], and SPUR cite:[spur-jsscc1989] were the first -four). We also pun on the use of the Roman numeral `V` to signify -"`variations`" and "`vectors`", as support for a range of architecture +four). We also pun on the use of the Roman numeral "V" to signify +"variations" and "vectors", as support for a range of architecture research, including various data-parallel accelerators, is an explicit goal of the ISA design. ==== @@ -60,7 +60,7 @@ 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 first ("`classic`") privileged +volume provides the design of the first ("classic") privileged architecture. The manuals use IEC 80000-13:2008 conventions, with a byte of 8 bits. @@ -128,7 +128,7 @@ 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 +* "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 defines an execution environment that begins at power-on reset. @@ -207,7 +207,7 @@ variable-length instruction encodings. A base is carefully restricted to a minimal set of instructions sufficient to provide a reasonable target for compilers, assemblers, linkers, and operating systems (with additional privileged operations), and so provides a convenient ISA and -software toolchain "`skeleton`" around which more customized processor +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 @@ -227,6 +227,9 @@ base integer instruction set supporting a flat 128-bit address space (XLEN=128). The base integer instruction sets use a two’s-complement representation for signed integer values. + +[TIP] +==== 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 @@ -260,7 +263,7 @@ be linked with 64-bit code, this is impractical in practice, even with compatible encodings, due to the differences in software calling conventions and system-call interfaces. -The RISC-V privileged architecture provides fields in `misa` to control +The RISC-V privileged architecture provides fields in "misa" to control the unprivileged ISA at each level to support emulating different base ISAs on the same hardware. We note that newer SPARC and MIPS ISA revisions have deprecated support for running 32-bit code unchanged on @@ -278,7 +281,7 @@ RISC-V design was changed to the current choice in January 2011. Our focus was on supporting 32-bit integers in the 64-bit ISA not on providing compatibility with the 32-bit ISA, and the motivation was to remove the asymmetry that arose from having not all opcodes in RV32I -have a *W suffix (e.g., ADDW, but AND not ANDW). In hindsight, this was +have a "W" suffix (e.g., ADDW, but AND not ANDW). In hindsight, this was perhaps not well-justified and a consequence of designing both ISAs at the same time as opposed to adding one later to sit on top of another, and also from a belief we had to fold platform requirements into the ISA @@ -286,9 +289,10 @@ spec which would imply that all the RV32I instructions would have been required in RV64I. It is too late to change the encoding now, but this is also of little practical consequence for the reasons stated above. -It has been noted we could enable the *W variants as an extension to +It has been noted we could enable the "W" variants as an extension to RV32I systems to provide a common encoding across RV64I and a future RV32 variant. +==== RISC-V has been designed to support extensive customization and specialization. Each base integer ISA can be extended with one or more @@ -316,20 +320,20 @@ in detail in <<naming>>. To support more general software development, a set of standard extensions are defined to provide integer multiply/divide, atomic operations, and single and double-precision floating-point arithmetic. -The base integer ISA is named `I` (prefixed by RV32 or RV64 depending +The base integer ISA is named "I" (prefixed by RV32 or RV64 depending on integer register width), and contains integer computational instructions, integer loads, integer stores, and control-flow instructions. The standard integer multiplication and division extension -is named `M`, and adds instructions to multiply and divide values held +is named "M", and adds instructions to multiply and divide values held in the integer registers. The standard atomic instruction extension, -denoted by `A`, adds instructions that atomically read, modify, and +denoted by "A", adds instructions that atomically read, modify, and write memory for inter-processor synchronization. The standard -single-precision floating-point extension, denoted by `F`, adds +single-precision floating-point extension, denoted by "F", adds floating-point registers, single-precision computational instructions, and single-precision loads and stores. The standard double-precision -floating-point extension, denoted by `D`, expands the floating-point +floating-point extension, denoted by "D", expands the floating-point registers, and adds double-precision computational instructions, loads, -and stores. The standard `C` compressed instruction extension provides +and stores. The standard "C" compressed instruction extension provides narrower 16-bit forms of common instructions. Beyond the base integer ISA and the standard GC extensions, we believe @@ -370,11 +374,14 @@ harts may be entirely the same, or entirely different, or may be partly different but sharing some subset of resources, mapped into the same or different address ranges. -For a purely "`bare metal`" environment, all harts may see an identical +[TIP] +==== +For a purely "bare metal" environment, all harts may see an identical address space, accessed entirely by physical addresses. However, when the execution environment includes an operating system employing address translation, it is common for each hart to be given a virtual address space that is largely or entirely its own. +==== (((memory access, implicit and explicit))) Executing each RISC-V machine instruction entails one or more memory @@ -458,61 +465,52 @@ instructions have larger values of ILEN. <<instlengthcode>> illustrates the standard RISC-V instruction-length encoding convention. All the 32-bit -instructions in the base ISA have their lowest two bits set to `11`. The +instructions in the base ISA have their lowest two bits set to "11". The optional compressed 16-bit instruction-set extensions have their lowest -two bits equal to `00`, `01`, or `10`. +two bits equal to "00", "01", or "10". ==== Expanded Instruction-Length Encoding -(((instruction length encoding))) A portion of the 32-bit instruction-encoding space has been tentatively allocated for instructions longer than 32 bits. The entirety of this space is reserved at this time, and the following proposal for encoding instructions longer than 32 bits is not considered frozen. +(((instruction length encoding))) Standard instruction-set extensions encoded with more than 32 bits have -additional low-order bits set to `1`, with the conventions for 48-bit +additional low-order bits set to "1", with the conventions for 48-bit and 64-bit lengths shown in <<instlengthcode>>. Instruction lengths between 80 bits and 176 bits are encoded using a 3-bit field in bits [14:12] giving the number of 16-bit words in addition to the first 5latexmath:[$\times$]16-bit words. The encoding with bits [14:12] set to -`111` is reserved for future longer instruction encodings. +"111" is reserved for future longer instruction encodings. [[instlengthcode]] -[cols="^,^,^,^,<",] +.RISC-V instruction length encoding. Only the 16-bit and 32-bit encodings are considered frozen at this time. +[cols="^2,^4,^3,^3,<2",] |=== | | | |`xxxxxxxxxxxxxxaa` |16-bit (`aa`≠`11`) -| | | | | - | | |`xxxxxxxxxxxxxxxx` |`xxxxxxxxxxxbbb11` |32-bit (`bbb`≠`111`) -| | | | | - | |latexmath:[$\cdot\cdot\cdot$]`xxxx` |`xxxxxxxxxxxxxxxx` |`xxxxxxxxxx011111` |48-bit -| | | | | - | |latexmath:[$\cdot\cdot\cdot$]`xxxx` |`xxxxxxxxxxxxxxxx` |`xxxxxxxxx0111111` |64-bit -| | | | | - | |latexmath:[$\cdot\cdot\cdot$]`xxxx` |`xxxxxxxxxxxxxxxx` |`xnnnxxxxx1111111` |(80+16*`nnn`)-bit, `nnn`≠`111` -| | | | | - | |latexmath:[$\cdot\cdot\cdot$]`xxxx` |`xxxxxxxxxxxxxxxx` |`x111xxxxx1111111` |Reserved for ≥192-bits -| | | | | - |Byte Address: |base+4 |base+2 |base | |=== +[NOTE] +==== Given the code size and energy savings of a compressed format, we wanted to build in support for a compressed format to the ISA encoding scheme rather than adding this as an afterthought, but to allow simpler @@ -533,14 +531,14 @@ Perhaps more importantly, by condensing our base ISA into a subset of the 32-bit instruction word, we leave more space available for non-standard and custom extensions. In particular, the base RV32I ISA uses less than 1/8 of the encoding space in the 32-bit instruction word. -As described in Chapter link:#extensions[[extensions]], an -implementation that does not require support for the standard compressed -instruction extension can map 3 additional non-conforming 30-bit -instruction spaces into the 32-bit fixed-width format, while preserving +As described <<extensions>>, an implementation that does not require support +for the standard compressed instruction extension can map 3 additional non-conforming +30-bit instruction spaces into the 32-bit fixed-width format, while preserving support for standard ≥32-bit instruction-set extensions. Further, if the implementation also does not need instructions >32-bits in length, it can recover a further four major opcodes for non-conforming extensions. +==== Encodings with bits [15:0] all zeros are defined as illegal instructions. These instructions are considered to be of minimal length: @@ -548,6 +546,8 @@ instructions. These instructions are considered to be of minimal length: bits. The encoding with bits [ILEN-1:0] all ones is also illegal; this instruction is considered to be ILEN bits long. +[TIP] +==== We consider it a feature that any length of instruction containing all zero bits is not legal, as this quickly traps erroneous jumps into zeroed memory regions. Similarly, we also reserve the instruction @@ -569,6 +569,7 @@ instruction-fetch unit on machines with ILEN >32 report an illegal instruction exception rather than an access-fault exception when such an instruction borders a protection boundary, complicating variable-instruction-length fetch and decode. +==== (((endian, little and big))) RISC-V base ISAs have either little-endian or big-endian memory systems, @@ -581,6 +582,8 @@ instruction specification. (((bi-endian))) (((endian, bi-))) +[TIP] +==== We originally chose little-endian byte ordering for the RISC-V memory system because little-endian systems are currently dominant commercially (all x86 systems; iOS, Android, and Windows for ARM). A minor point is @@ -616,12 +619,10 @@ the byte order when storing to instruction memory. Once we had decided to fix on a little-endian instruction encoding, this naturally led to placing the length-encoding bits in the LSB positions of the instruction format to avoid breaking up opcode fields. +==== [[trap-defn]] === Exceptions, Traps, and Interrupts -(((exceptions))) -(((traps))) -(((interrupts))) We use the term _exception_ to refer to an unusual condition occurring at run time associated with an instruction in the current RISC-V hart. @@ -629,6 +630,9 @@ We use the term _interrupt_ to refer to an external asynchronous event that may cause a RISC-V hart to experience an unexpected transfer of control. We use the term _trap_ to refer to the transfer of control to a trap handler caused by either an exception or an interrupt. +(((exceptions))) +(((traps))) +(((interrupts))) The instruction descriptions in following chapters describe conditions that can raise an exception during execution. The general behavior of @@ -638,8 +642,11 @@ which, in the standard floating-point extensions, do not cause traps). The manner in which interrupts are generated, routed to, and enabled by a hart depends on the EEI. -Our use of "`exception`" and "`trap`" is compatible with that in the +[NOTE] +==== +Our use of "exception" and "trap" is compatible with that in the IEEE-754 floating-point standard. +==== How traps are handled and made visible to software running on the hart depends on the enclosing execution environment. From the perspective of @@ -681,8 +688,7 @@ Fatal Trap::: kind of trap. [[trapcharacteristics]] -.Characteristics of traps; 1) Termination may be requested. 2) -Imprecise fatal traps might be observable by software. +.Characteristics of traps: 1) Termination may be requested. 2) Imprecise fatal traps might be observable by software. [cols="<,^,^,^,^",options="header",] |=== | |Contained |Requested |Invisible |Fatal @@ -710,13 +716,13 @@ encodings that are not defined here and not defined by some other means may cause a fatal trap. === UNSPECIFIED Behaviors and Values -(((unspecified, behaviors))) -(((unspecified, values))) The architecture fully describes what implementations must do and any constraints on what they may do. In cases where the architecture intentionally does not constrain implementations, the term is explicitly used. +(((unspecified, behaviors))) +(((unspecified, values))) The term _unspecified_ refers to a behavior or value that is intentionally unconstrained. The definition of these behaviors or values is open to diff --git a/src/q-st-ext.adoc b/src/q-st-ext.adoc index 344857d..f1571b3 100644 --- a/src/q-st-ext.adoc +++ b/src/q-st-ext.adoc @@ -3,7 +3,7 @@ This chapter describes the Q standard extension for 128-bit quad-precision binary floating-point instructions compliant with the IEEE 754-2008 arithmetic standard. The quad-precision binary -floating-point instruction-set extension is named `Q`; it depends on +floating-point instruction-set extension is named "Q"; it depends on the double-precision floating-point extension D. The floating-point registers are now extended to hold either a single, double, or quad-precision floating-point value (FLEN=128). The NaN-boxing scheme @@ -35,7 +35,7 @@ instructions, as shown in <<fpextfmt>> [[fpextfmt]] .Format field encoding. -[cols="^,^,<",options="header",] +[cols="^1,^1,<3",options="header",] |=== |_fmt_ field |Mnemonic |Meaning |00 |S |32-bit single-precision @@ -102,7 +102,7 @@ memory. RV128 will support FMV.X.Q and FMV.Q.X in the Q extension. ==== -=== Quad-precision floating-Point compare +=== Quad-precision floating-Point compare insturctions The quad-precision floating-point compare instructions are defined analogously to their double-precision counterparts, but operate on diff --git a/src/riscv-isa-unpr-conv-review.pdf b/src/riscv-isa-unpr-conv-review.pdf Binary files differindex 25d0d98..5a9d57a 100644 --- a/src/riscv-isa-unpr-conv-review.pdf +++ b/src/riscv-isa-unpr-conv-review.pdf diff --git a/src/rv128.adoc b/src/rv128.adoc index 47b4068..2440753 100644 --- a/src/rv128.adoc +++ b/src/rv128.adoc @@ -2,9 +2,9 @@ == RV128I Base Integer Instruction Set, Version 1.7 ==== -_"There is only one mistake that can be made in computer design that is +"There is only one mistake that can be made in computer design that is difficult to recover from—not having enough address bits for memory -addressing and memory management."_ Bell and Strecker, ISCA-3, 1976. +addressing and memory management." Bell and Strecker, ISCA-3, 1976. ==== This chapter describes RV128I, a variant of the RISC-V ISA supporting a diff --git a/src/rv32.adoc b/src/rv32.adoc index 858230b..23371ac 100644 --- a/src/rv32.adoc +++ b/src/rv32.adoc @@ -29,13 +29,16 @@ instructions as a single trap. ==== The standard RISC-V assembly language syntax is documented in the Assembly Programmer’s Manual cite:[riscv-asm-manual]. +==== +[NOTE] +==== Most of the commentary for RV32I also applies to the RV64I base. ==== === Programmers’ Model for Base Integer ISA -<<img-gprs>> shows the unprivileged state for the base +<<gprs>> shows the unprivileged state for the base integer ISA. For RV32I, the 32 `x` registers are each 32 bits wide, i.e., XLEN=32. Register `x0` is hardwired with all bits equal to 0. General purpose registers `x1`–`x31` hold values that various @@ -45,9 +48,48 @@ complement signed binary integers or unsigned binary integers. There is one additional unprivileged register: the program counter `pc` holds the address of the current instruction. -[[img-gprs]] +[[gprs]] .RISC-V base unprivileged integer register state. -image::base-unpriv-reg-state.png[base,180,1000,align="center"] +[col[s="<|^|>"|option[s="header",width="50%",align="center"grid="none"] +|=== +<| [.small]#XLEN-1#| >| [.small]#0# +3+^| [.small]#x0/zero# +3+^| [.small]#x1# +3+^| [.small]#x2# +3+^| [.small]#x3# +3+^| [.small]#x4# +3+^| [.small]#x5# +3+^| [.small]#x6# +3+^| [.small]#x7# +3+^| [.small]#x8# +3+^| [.small]#x9# +3+^| [.small]#x10# +3+^| [.small]#x11# +3+^| [.small]#x12# +3+^| [.small]#x13# +3+^| [.small]#x14# +3+^| [.small]#x15# +3+^| [.small]#x16# +3+^| [.small]#x17# +3+^| [.small]#x18# +3+^| [.small]#x19# +3+^| [.small]#x20# +3+^| [.small]#x21# +3+^| [.small]#x22# +3+^| [.small]#x23# +3+^| [.small]#x24# +3+^| [.small]#x25# +3+^| [.small]#x26# +3+^| [.small]#x27# +3+^| [.small]#x28# +3+^| [.small]#x29# +3+^| [.small]#x30# +3+^| [.small]#x31# +3+^| [.small]#XLEN# +| [.small]#31#| >| [.small]#0# +3+^| [.small]#pc# +3+^| [.small]#XLEN# +|=== There is no dedicated stack pointer or subroutine return address link register in the Base Integer ISA; the instruction encoding allows any @@ -972,7 +1014,7 @@ simulation/emulation. |=== |Instruction |Constraints |Code Points |Purpose -|LUI |_rd_=`x0` |latexmath:[$2^{20}$] .18+<.>m|_Reserved for future standard use_ +|LUI |_rd_=`x0` |latexmath:[$2^{20}$] .18+<.^m|_Reserved for future standard use_ |AUIPC |_rd_=`x0` |latexmath:[$2^{20}$] @@ -1010,7 +1052,7 @@ simulation/emulation. |FENCE |_rd_=_rs1_=`x0`, _fm_=0, _pred_=W, _succ_=0 |1 |PAUSE -|SLTI |_rd_=`x0` |latexmath:[$2^{17}$] .7+<.>m|_Designated for custom use_ +|SLTI |_rd_=`x0` |latexmath:[$2^{17}$] .7+<.^m|_Designated for custom use_ |SLTIU|_rd_=`x0` |latexmath:[$2^{17}$] diff --git a/src/rv32e.adoc b/src/rv32e.adoc index 775771f..afa30ca 100644 --- a/src/rv32e.adoc +++ b/src/rv32e.adoc @@ -23,7 +23,7 @@ an RV64E to reduce context state for highly threaded 64-bit processors. === RV32E Programmers’ Model RV32E reduces the integer register count to 16 general-purpose -registers, (`x0`–`x15`), where `x0` is a dedicated zero register. +registers, (`x0–x15`), where `x0` is a dedicated zero register. [TIP] ==== @@ -42,7 +42,7 @@ RV32I. (((RV32E, difference from RV32I))) RV32E uses the same instruction-set encoding as RV32I, except that only -registers `x0`–`x15` are provided. Any future standard extensions will +registers `x0–x15` are provided. Any future standard extensions will not make use of the instruction bits freed up by the reduced register-specifier fields and so these are designated for custom extensions. diff --git a/src/rv64.adoc b/src/rv64.adoc index 36bcf23..3e90eb3 100644 --- a/src/rv64.adoc +++ b/src/rv64.adoc @@ -99,9 +99,12 @@ AUIPC forms a 32-bit offset from the U-immediate, filling in the lowest address of the AUIPC instruction, then places the result in register _rd_. +[NOTE] +==== Note that the set of address offsets that can be formed by pairing LUI with LD, AUIPC with JALR, etc.in RV64I is [latexmath:[${-}2^{31}{-}2^{11}$], latexmath:[$2^{31}{-}2^{11}{-}1$]]. +==== ==== Integer Register-Register Operations @@ -171,7 +174,7 @@ no standard HINTs will ever be defined in this subspace. [options="header",] |=== |Instruction |Constraints |Code Points |Purpose -|LUI |_rd_=_x0_ |latexmath:[$2^{20}$] .24+|_Reserved for future standard use_ +|LUI |_rd_=_x0_ |latexmath:[$2^{20}$] .24+.^|_Reserved for future standard use_ |AUIPC |_rd_=_x0_ |latexmath:[$2^{20}$] @@ -225,7 +228,7 @@ no standard HINTs will ever be defined in this subspace. |_rd_=_rs1_=_x0_, _fm_=0, _pred_=W, _succ_=0 |1 | PAUSE -|SLTI |_rd_=_x0_ |latexmath:[$2^{17}$] .10+|_Designated for custom use_ +|SLTI |_rd_=_x0_ |latexmath:[$2^{17}$] .10+.^|_Designated for custom use_ |SLTIU |_rd_=_x0_ |latexmath:[$2^{17}$] diff --git a/src/zicsr.adoc b/src/zicsr.adoc index ad8a916..2a1ddbd 100644 --- a/src/zicsr.adoc +++ b/src/zicsr.adoc @@ -1,5 +1,5 @@ [[csrinsts]] -== Zicsr, Control and Status Register (CSR) Instructions, Version 2.0 +== "Zicsr" Control and Status Register (CSR) Instructions, Version 2.0 RISC-V defines a separate address space of 4096 Control and Status registers associated with each hart. This chapter defines the full set @@ -18,7 +18,6 @@ chapter. ==== === CSR Instructions -((CSR)) All CSR instructions atomically read-modify-write a single CSR, whose CSR specifier is encoded in the 12-bit _csr_ field of the instruction @@ -89,6 +88,7 @@ effects regardless of _rd_ and _rs1_ fields. [cols="<,^,^,^,^",options="header",] |=== |_Register operand_| | | | + |Instruction |_rd_ is `x0` |_rs1_ is `x0` |Reads CSR |Writes CSR |CSRRW |Yes |– |No |Yes @@ -101,8 +101,7 @@ effects regardless of _rd_ and _rs1_ fields. |_Immediate operand_| | | | -|Instruction |_rd_ is `x0` |_uimm_ latexmath:[$=$]0 |Reads CSR |Writes -CSR +|Instruction |_rd_ is `x0` |_uimm_ latexmath:[$=$]0 |Reads CSR |Writes CSR |CSRRWI |Yes |– |No |Yes @@ -223,7 +222,7 @@ such CSRs (e.g., taking an interrupt because of a change in `mip`) are also ordered as device input. ==== -Most CSRs (including, e.g., the `fcsr`) are not visible to other harts; +Most CSRs (including, e.g., the "fcsr") are not visible to other harts; their accesses can be freely reordered in the global memory order with respect to FENCE instructions without violating this specification. diff --git a/src/zifencei.adoc b/src/zifencei.adoc index 48b4440..27c3ca8 100644 --- a/src/zifencei.adoc +++ b/src/zifencei.adoc @@ -1,7 +1,7 @@ [[zifencei]] -== `Zifencei` Instruction-Fetch Fence, Version 2.0 +== "Zifencei" Instruction-Fetch Fence, Version 2.0 -This chapter defines the 'Zifencei' extension, which includes the +This chapter defines the _Zifencei_ extension, which includes the FENCE.I instruction that provides explicit synchronization between writes to instruction memory and instruction fetches on the same hart. Currently, this instruction is the only standard mechanism to ensure |