From: lkcl <lkcl@web>
Date: Sun, 11 Jun 2023 22:36:07 +0000 (+0100)
Subject: (no commit message)
X-Git-Url: https://git.libre-soc.org/?a=commitdiff_plain;h=617c87483f0b3bf854b2228e3f45c8aaaa6f40c2;p=libreriscv.git

---

diff --git a/openpower/sv/svp64.mdwn b/openpower/sv/svp64.mdwn
index 8d732f474..c623c123a 100644
--- a/openpower/sv/svp64.mdwn
+++ b/openpower/sv/svp64.mdwn
@@ -118,40 +118,27 @@ only 24 bits:
 Different classes of operations require different formats. The earlier
 sections cover the common formats and the five separate modes have their own
 section later:
+
 * CR operations (crops),
 * Arithmetic/Logical (termed "normal"),
 * Load/Store Immediate,
 * Load/Store Indexed,
 * Branch-Conditional.
 
-## Definition of Reserved in this spec.
-
-For the new fields added in SVP64, instructions that have any of their
-fields set to a reserved value must cause an illegal instruction trap,
-to allow emulation of future instruction sets, or for subsets of SVP64 to
-be implemented in hardware and the rest emulated.  This includes SVP64
-SPRs: reading or writing values which are not supported in hardware
-must also raise illegal instruction traps in order to allow emulation.
-Unless otherwise stated, reserved values are always all zeros.
-
-This is unlike OpenPower ISA v3.1, which in many instances does not
-require a trap if reserved fields are nonzero, instead relying on software
-to avoid use of such fields.  Where the standard Power
-ISA definition is intended the red keyword `RESERVED` is used.
-
 ## Definition of "PO9-Prefixed"
 
 Used in the context of "A PO9-Prefixed Word" this is a new area similar to EXT100-163
 that is shared between SVP64-Single, SVP64, 32 Vectorizable new Opcode areas
-EXT200-231, one RESERVED 57-bit future Opcode space, and three new Unvectorizable
-RESERVED 32-bit future Opcode spaces. See [[sv/po9_encoding]].
+EXT232-263, and a 32-bit area, EXT900, that is also Vectorizable
+and SVP64-Single extensible in future. See [[sv/po9_encoding]].
 
 ## Definition of "SVP64-Prefix"
 
-A 24-bit RISC-Paradigm Encoding area for Loop-Augmentation of the following
+A 24-bit RISC-Paradigm Encoding area for Loop-Augmentation of the
+next
 "Defined Word-instruction-instruction".
 Used in the context of "An SVP64-Prefixed Defined Word-instruction", as separate and
-distinct from the 32-bit PO9-Prefix that holds a 24-bit SVP64 Prefix.
+distinct from the 32-bit PO9-Prefix that *holds* a 24-bit SVP64 Prefix.
 
 ##  Definition of "Vectorizable" and "Unvectorizable"
 
@@ -163,7 +150,7 @@ Vector Loop is termed
 which have no registers. `mtmsr` is also classed as Unvectorizable
 because there is only one `MSR`.
 
-UnVectorized instructions are required to be detected as such if
+Unvectorized instructions are required to be detected as such if
 Prefixed (either SVP64 or SVP64Single) and an Illegal Instruction
 Trap raised.
 
@@ -181,14 +168,14 @@ without also adding hardware support for SVP64-Prefixing of the same.*
 
 *ISA Working Group note: Vectorized PackedSIMD instructions if ever proposed
 should be considered Unvectorizable and except in extreme mitigating circumstances
-rejected outright.*
+rejected immediately.*
 
 ## Definition of Strict Element-Level Execution Order<a name="svp64_eeo"> </a>
 
 Where Instruction Execution Order[^ieo] guarantees the appearance of sequential
 execution of instructions, Simple-V requires a corresponding guarantee for Elements
-because in Simple-V Execution of Elements is synonymous with Execution of
-instructions.
+because in Simple-V "Execution of Elements" is synonymous with "Execution of
+instructions".
 
 [^ieo]: Strict Instruction Execution Order is defined in Public v3.1 Book I Section 2.2