1 files changed, 0 insertions, 71 deletions
diff --git a/src/rv128.tex b/src/rv128.tex
deleted file mode 100644
index 64515e3..0000000
--- a/src/rv128.tex
+++ /dev/null
@@ -1,71 +0,0 @@
-\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.
-
-\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.
-
-