(no commit message)

diff --git a/simple_v_extension/vblock_format/discussion.mdwn b/simple_v_extension/vblock_format/discussion.mdwn
index c9f94f9bd19f2d17b93c33a2deca774fc88f3f24..257799fcf6982a16a20dbc039e33542e3b81ca3c 100644 (file)
--- a/simple_v_extension/vblock_format/discussion.mdwn
+++ b/simple_v_extension/vblock_format/discussion.mdwn
@@ -82,24 +82,24 @@ Example (contrived):
 * The specification for the 3rd add is therefore
   "ADD scalar-x9, scalar-x4, scalar-x4"
 * The 4th instruction. **despite** using x7 as vector in instruction 2, x7 is **not** listed in the 1st instruction's operands. Likewise for x4. Therefore the "OR" rule applies to them.
-* x5 on the other hand *is* in the 1st instruction's operands, and, given that x4 abd x7 have the "OR" rule applied, are also marked as "vector" *despite x4 being fornerly scalar in the 3rd instruction*.
+* x5 on the other hand *is* in the 1st instruction's operands, and, given that x4 and x7 have the "OR" rule applied, are also marked as "vector" *despite x4 being fornerly scalar in the 3rd instruction*.
 * Therefore, the "full" specification for the 4th add is:
   "ADD vector-x7, vector-x5, vector-x4"
 
 Writing those out separately, for clarity:
 
-  ADD vector-x3, vector-x5, scalar-x12 # from vs1=1, vs2=0, vd=vs1|vs2  
-  ADD vector-x7, vector-x5, vector-x3  # x7: v-x5 | v-x3  
-  ADD scalar-x9, scalar-x4, scalar-x4  # x9, x4 not prefixed, therefore scalar  
-  ADD vector-x7, vector-x5, vector-x4  # x4, x7, x5 vector  
+    ADD vector-x3, vector-x5, scalar-x12 # from vs1=1, vs2=0, vd=vs1|vs2  
+    ADD vector-x7, vector-x5, vector-x3  # x7: v-x5 | v-x3  
+    ADD scalar-x9, scalar-x4, scalar-x4  # x9, x4 not prefixed, therefore scalar  
+    ADD vector-x7, vector-x5, vector-x4  # x4, x7, x5 vector  
 
-Twin-SVP mode allows certain registers to be explicitly marked as "scalar",
-where some of the rules might otherwise start to cascade through and cause
+Twin-SVP mode allows even more registers to be explicitly marked, including some specifically as "scalar",
+where the rules might otherwise start to cascade through and cause
 registers to be come undesirably marked as "vectors".
 
-The reason why the OR rule cannot cascade onwards is because if a trap occurs and the context has to be reestablished, it may be reestablished purely with the VBLOCK header and by decoding the first (and second) instruction.
+The reason why the OR rule cannot cascade onwards is because if a trap occurs and the context has to be reestablished on return, it may be reestablished purely with the VBLOCK header and by decoding the first (and second) instruction.
 
-If the cascade of what was marked "vector" was allowed to continue, it would require re-reading of every opcode up to the point where execution of the VBLOCK left off, on order to reestablish the full cascade context.
+If the cascade of what was marked "vector" was allowed to continue, it would require re-reading of every opcode up to the point where execution of the VBLOCK left off, in order to reestablish the full cascade context.
 
 # Discussion