(no commit message)

diff --git a/openpower/sv/svp64/appendix.mdwn b/openpower/sv/svp64/appendix.mdwn
index 5d51e34813f212f7989f6aed98fdd19eb062f9ed..c6b25a4c27c01541676c0e8f9c702e97a569b6f9 100644 (file)
--- a/openpower/sv/svp64/appendix.mdwn
+++ b/openpower/sv/svp64/appendix.mdwn
@@ -81,66 +81,6 @@ may be performed by setting VL=8, and a one-instruction
 1024-bit Add-with-Carry by setting VL=16, and so on.  More on
 this in [[openpower/sv/biginteger]]
 
-# v3.0B/v3.1 relevant instructions
-
-SV is primarily designed for use as an efficient hybrid 3D GPU / VPU /
-CPU ISA.
-
-Vectorisation of the VSX Packed SIMD system makes no sense whatsoever,
-the sole exceptions potentially being any operations with 128-bit
-operands such as `vrlq` (Rotate Quad Word) and `xsaddqp` (Scalar
-Quad-precision Add).
-SV effectively *replaces* the majority of VSX, requiring far less 
-instructions, and provides, at the very minimum, predication
-(which VSX was designed without).
-
-Likewise, Load/Store Multiple make no sense to
-have because they are not only provided by SV, the SV alternatives may
-be predicated as well, making them far better suited to use in function
-calls and context-switching.
-
-Additionally, some v3.0/1 instructions simply make no sense at all in a
-Vector context: `rfid` falls into this category,
-as well as `sc` and `scv`.  Here there is simply no point
-trying to Vectorise them: the standard OpenPOWER v3.0/1 instructions
-should be called instead.
-
-Fortuitously this leaves several Major Opcodes free for use by SV
-to fit alternative future instructions.  In a 3D context this means
-Vector Product, Vector Normalise, [[sv/mv.swizzle]], Texture LD/ST
-operations, and others critical to an efficient, effective 3D GPU and
-VPU ISA. With such instructions being included as standard in other
-commercially-successful GPU ISAs it is likewise critical that a 3D
-GPU/VPU based on svp64 also have such instructions.
-
-Note however that svp64 is stand-alone and is in no way
-critically dependent on the existence or provision of 3D GPU or VPU
-instructions. These should be considered entirely separate
-extensions, and their discussion
-and specification is out of scope for this document.
-
-## Major opcode map (v3.0B)
-
-This table is taken from v3.0B.
-Table 9: Primary Opcode Map (opcode bits 0:5)
-
-```
-    |  000   |   001 |  010  | 011   |  100  |    101 |  110  |  111
-000 |        |       |  tdi  | twi   | EXT04 |        |       | mulli | 000
-001 | subfic |       | cmpli | cmpi  | addic | addic. | addi  | addis | 001
-010 | bc/l/a | EXT17 | b/l/a | EXT19 | rlwimi| rlwinm |       | rlwnm | 010
-011 |  ori   | oris  | xori  | xoris | andi. | andis. | EXT30 | EXT31 | 011
-100 |  lwz   | lwzu  | lbz   | lbzu  | stw   | stwu   | stb   | stbu  | 100
-101 |  lhz   | lhzu  | lha   | lhau  | sth   | sthu   | lmw   | stmw  | 101
-110 |  lfs   | lfsu  | lfd   | lfdu  | stfs  | stfsu  | stfd  | stfdu | 110
-111 |  lq    | EXT57 | EXT58 | EXT59 | EXT60 | EXT61  | EXT62 | EXT63 | 111
-    |  000   |   001 |   010 |  011  |   100 |   101  | 110   |  111
-```
-
-It is important to note that having a different v3.0B Scalar opcode
-that is different from an SVP64 one is highly undesirable: the complexity
-in the decoder is greatly increased, through breaking of the RISC paradigm.
-
 # EXTRA Field Mapping
 
 The purpose of the 9-bit EXTRA field mapping is to mark individual