move vector block format. clarify exceptions

diff --git a/simple_v_extension/abridged_spec.mdwn b/simple_v_extension/abridged_spec.mdwn
index 9cf284f448cd59f816263474a86433c6754d36d3..5032eb51a63024ab29b4f682ec914b27314837f5 100644 (file)
--- a/simple_v_extension/abridged_spec.mdwn
+++ b/simple_v_extension/abridged_spec.mdwn
@@ -239,9 +239,24 @@ to be set.
 
 See [[appendix]] for more details on fail-on-first modes.
 
+# Vector Block Format <a name="vliw-format"></a>
+
+The Vector Block format uses the RISC-V 80-192 bit format from Section 1.5
+of the RISC-V Spec.  It permits an optional VL/MVL/SUBVL block, up to 4
+16-bit (or 8 8-bit) Register Table entries, the same for Predicate Entries,
+and the rest of the instruction may be either standard RV opcodes or the
+SVPrefix opcodes ([[sv_prefix_proposal]])
+
+[[!inline raw="yes" pages="simple_v_extension/vblock_format_table" ]]
+
+For full details see ancillary resource: [[vblock_format]]
+
 # Exceptions
 
-TODO: expand.  
+Exception handling **MUST** be precise, in-order, and exactly
+like Standard RISC-V as far as the instruction execution order is
+concerned, regardless of whether it is PC, PCVBLK, VL or SUBVL that
+is currently being incremented.
 
 # Hints
 
@@ -253,18 +268,6 @@ in as a *parameter* to the HINT operation.
 
 No specific hints are yet defined in Simple-V
 
-# Vector Block Format <a name="vliw-format"></a>
-
-The Vector Block format uses the RISC-V 80-192 bit format from Section 1.5
-of the RISC-V Spec.  It permits an optional VL/MVL/SUBVL block, up to 4
-16-bit (or 8 8-bit) Register Table entries, the same for Predicate Entries,
-and the rest of the instruction may be either standard RV opcodes or the
-SVPrefix opcodes ([[sv_prefix_proposal]])
-
-[[!inline raw="yes" pages="simple_v_extension/vblock_format_table" ]]
-
-For full details see ancillary resource: [[vblock_format]]
-
 # Subsets of RV functionality
 
 It is permitted to only implement SVprefix and not the VBLOCK instruction

diff --git a/simple_v_extension/specification.mdwn b/simple_v_extension/specification.mdwn
index c4250a5cd37fe544c94498403c82a1ad66f2aa21..9beec1ecd9878e9568db32a4be9517f457494c8d 100644 (file)
--- a/simple_v_extension/specification.mdwn
+++ b/simple_v_extension/specification.mdwn
@@ -710,22 +710,25 @@ See [[appendix]]
 
 # Exceptions
 
-TODO: expand.  Exceptions may occur at any time, in any given underlying
-scalar operation.  This implies that context-switching (traps) may
-occur, and operation must be returned to where it left off.  That in
-turn implies that the full state - including the current parallel
-element being processed - has to be saved and restored.  This is
-what the **STATE** CSR is for.
+Exceptions may occur at any time, in any given underlying scalar
+operation.  This implies that context-switching (traps) may occur, and
+operation must be returned to where it left off.  That in turn implies
+that the full state - including the current parallel element being
+processed - has to be saved and restored.  This is what the **STATE**
+and **PCVBLK** CSRs are for.
 
 The implications are that all underlying individual scalar operations
 "issued" by the parallelisation have to appear to be executed sequentially.
 The further implications are that if two or more individual element
 operations are underway, and one with an earlier index causes an exception,
-it may be necessary for the microarchitecture to **discard** or terminate
-operations with higher indices.
-
-This being somewhat dissatisfactory, an "opaque predication" variant
-of the STATE CSR is being considered.
+it will be necessary for the microarchitecture to **discard** or terminate
+operations with higher indices.  Optimisated microarchitectures could
+hypothetically store (cache) results, for subsequent replay if appropriate.
+
+In short: exception handling **MUST** be precise, in-order, and exactly
+like Standard RISC-V as far as the instruction execution order is
+concerned, regardless of whether it is PC, PCVBLK, VL or SUBVL that
+is currently being incremented.
 
 # Hints