aboutsummaryrefslogtreecommitdiff
path: root/src/rv128.tex
diff options
context:
space:
mode:
Diffstat (limited to 'src/rv128.tex')
-rw-r--r--src/rv128.tex64
1 files changed, 64 insertions, 0 deletions
diff --git a/src/rv128.tex b/src/rv128.tex
new file mode 100644
index 0000000..17075d0
--- /dev/null
+++ b/src/rv128.tex
@@ -0,0 +1,64 @@
+\chapter{RV128I Base Integer Instruction Set, Version 1.7}
+\label{rv128}
+
+\begin{quote}
+{\em ``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.
+\end{quote}
+
+This chapter describes RV128I, a variant of the RISC-V ISA
+supporting a flat 128-bit address space. The variant is a
+straightforward extrapolation of the existing RV32I and RV64I designs.
+
+\begin{commentary}
+The primary reason to extend integer register width is to support
+larger address spaces. It is not clear when a flat address space larger
+than 64 bits will be required. At the time of writing, the fastest
+supercomputer in the world as measured by the Top500 benchmark had
+over \wunits{1}{PB} of DRAM, and would require over 50 bits of address
+space if all the DRAM resided in a single address space. Some
+warehouse-scale computers already contain even larger quantities of
+DRAM, and new dense solid-state non-volatile memories and fast
+interconnect technologies might drive a demand for even larger memory
+spaces. Exascale systems research is targeting \wunits{100}{PB}
+memory systems, which occupy 57 bits of address space. At historic
+rates of growth, it is possible that greater than 64 bits of address
+space might be required before 2030.
+
+History suggests that whenever it becomes clear that more than 64 bits
+of address space is needed, architects will repeat intensive debates
+about alternatives to extending the address space, including
+segmentation, 96-bit address spaces, and software workarounds, until,
+finally, flat 128-bit address spaces will be adopted as the simplest
+and best solution.
+
+We have not frozen the RV128 spec at this time, as there might be need
+to evolve the design based on actual usage of 128-bit address spaces.
+\end{commentary}
+
+RV128I builds upon RV64I in the same way RV64I builds upon RV32I, with
+integer registers extended to 128 bits (i.e., XLEN=128). Most integer
+computational instructions are unchanged as they are defined to
+operate on XLEN bits. The RV64I ``*W'' integer instructions that
+operate on 32-bit values in the low bits of a register are retained,
+and a new set of ``*D'' integer instructions that operate on 64-bit
+values held in the low bits of the 128-bit integer registers are
+added. The ``*D'' instructions consume two major opcodes (OP-IMM-64
+and OP-64) in the standard 32-bit encoding.
+
+Shifts by an immediate (SLLI/SRLI/SRAI) are now encoded using the low
+7 bits of the I-immediate, and variable shifts (SLL/SRL/SRA) use the
+low 7 bits of the shift amount source register.
+
+A LDU (load double unsigned) instruction is added using the existing
+LOAD major opcode, along with new LQ and SQ instructions to load and
+store quadword values. SQ is added to the STORE major opcode, while
+LQ is added to the MISC-MEM major opcode.
+
+The floating-point instruction set is unchanged, although the 128-bit
+Q floating-point extension can now support FMV.X.Q and FMV.Q.X
+instructions, together with additional FCVT instructions to and from
+the T (128-bit) integer format.
+
+