(no commit message)

diff --git a/openpower/sv/svp64.mdwn b/openpower/sv/svp64.mdwn
index 1942922f886c8babc1dba0a094fa93511adb6e4d..2a9c6f2c0ec9ab8d92c942397636d9c2f7b657f4 100644 (file)
--- a/openpower/sv/svp64.mdwn
+++ b/openpower/sv/svp64.mdwn
@@ -191,15 +191,24 @@ without also adding hardware support for SVP64-Prefixing of the same.*
 should be considered Unvectorizable and except in extreme mitigating circumstances
 rejected outright.*
 
-## Definition of Strict Program Order
+## Definition of Strict Element-Level Execution Order<a name="svp64_eeo"> </a>
 
-Strict Program Order is defined as giving the appearance, as far
+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.
+
+## Precise Interrupt Guarantees
+
+Strict Instruction Execution Order[^ieo] is defined as giving the appearance, as far
 as programs are concerned, that instructions were executed
 strictly in the sequence that they occurred.  A "Precise"
 out-of-order
 Micro-architecture goes to considerable lengths to ensure that
 this is the case.
 
+[^ieo]: Strict Instruction Execution Order is defined in Public v3.1 Book I Section 2.2
+
 Many Vector ISAs allow interrupts to occur in the middle of
 processing of large Vector operations, only under the condition
 that partial results are cleanly discarded, and continuation on return
@@ -211,27 +220,24 @@ that specifies a higher degree of accuracy for the *internal*
 accumulator than the registers.
 
 Simple-V operates on an entirely different paradigm from traditional
-Vector ISAs: as a Sub-Program Counter where "Elements" are synonymous
+Vector ISAs: as a "Sub-Execution Context", where "Elements" are synonymous
 with Scalar instructions. With this in mind it is critical for
-implementations to observe Strict Element-Level Program Order
-at all times
-(often simply referred to as just "Strict Program Order"
-throughout
-this Chapter).
-*Any* element is Interruptible and Simple-V has
-been carefully designed to guarantee that Architectural State may
-be fully preserved and restored regardless of that same State, but
-it is not necessarily guaranteed that the amount of time needed to recover
-will be low latency (particularly if REMAP
-is active).
+implementations to observe Strict **Element**-Level Execution Order[^svp64_eeo]
+at all times.
+*Any* element is Interruptible and Architectural State may
+be fully preserved and restored regardless of that same State
+
+*Engineering note: implementations are permitted have higher latency to
+perform context-switching  (particularly if REMAP
+is active).*
 
 Interrupts still only save `MSR` and `PC` in `SRR0` and `SRR1`
 but the full SVP64 Architectural State may be saved and
 restored through manual copying of `SVSTATE` (and the four
 REMAP SPRs if in use at the time)
-Whilst this initially sounds unsafe in reality
-all that Trap Handlers (and function call stack save/restore)
-need do is avoid
+
+*Programmer's note: Trap Handlers (and function call stack save/restore)
+may avoid the
 use of SVP64 Prefixed instructions to perform the necessary
 save/restore of Simple-V Architectural State.
 This capability also allows nested function calls to be made from