Vertical-First typically executes just the **one** scalar element
in each Vectorised operation. That element is selected by srcstep
and dststep *neither of which are changed as a side-effect of execution*.
-
-To create loops, either a new instruction `svstep` must be called,
-explicitly, or [[sv/branches]] must be given a mode bit to request
-explicit incrementation of srcstep and dststep.
+Illustrating this in pseodocode, with a branch/loop.
+To create loops, a new instruction `svstep` must be called,
+explicitly, with Rc=1:
+
+```
+loop:
+ sv.addi r0.v, r8.v, 5 # GPR(0+dststep) = GPR(8+srcstep) + 5
+ sv.addi r0.v, r8, 5 # GPR(0+dststep) = GPR(8 ) + 5
+ sv.addi r0, r8.v, 5 # GPR(0 ) = GPR(8+srcstep) + 5
+ svstep. # srcstep++, dststep++, CR0.eq = srcstep==VL
+ beq loop
+```
+
+Three examples are illustrated of different types of Scalar-Vector
+operations. Note that in its simplest form **only one** element is
+executed per instruction **not** multiple elements per instruction.
Now that such explicit loops can increment inexorably towards VL,
of course we now need a way to test if srcstep or dststep have reached
where CR0 will be updated if VL is reached. A standard v3.0B Branch
Conditional may rely on that. Alternatively, the number of elements
may be transferred into CTR, as is standard practice in Power ISA.
-The other method is to use SVP64 augmented [[sv/branches]] where the
-stepping updates the CR Field referenced by `BI` before proceeding
-with the Branch Condition test.
-
+Here, SVP64 [[sv/branches]] have a mode which allows CTR to be decremented
+by the number of vertical elements executed.
# Instruction format