1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
|
\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
but now sign extend their results from bit 31 to bit 127. A new set of
``*D'' integer instructions are added that operate on 64-bit values
held in the low bits of the 128-bit integer registers and sign extend
their results from bit 63 to bit 127. The ``*D'' instructions consume
two major opcodes (OP-IMM-64 and OP-64) in the standard 32-bit
encoding.
\begin{commentary}
To improve compatibility with RV64, in a reverse of how RV32 to RV64
was handled, we might change the decoding around to rename RV64I ADD
as a 64-bit ADDD, and add a 128-bit ADDQ in what was previously the
OP-64 major opcode (now renamed the OP-128 major opcode).
\end{commentary}
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.
|
