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
74
75
76
|
[[rv128]]
== RV128I Base Integer Instruction Set, Version 1.7
"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.
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.
(((RV128, design)))
[TIP]
====
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 1PB 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 100PB 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.
====
(((RV128, evolution)))
(((RV128I, as relates to RV64I)))
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.
(((RV128I, compatibility with RV64)))
[NOTE]
====
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).
====
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.
(((RV128I, LOU)))
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.
|
