(no commit message)

[libreriscv.git] / openpower / sv / svp64_quirks.mdwn

diff --git a/openpower/sv/svp64_quirks.mdwn b/openpower/sv/svp64_quirks.mdwn
index ec64b94291dd80fedd2860c0731805c213517a3f..2b43e255c0afc8fca1725a2f64fc2a421e10af6a 100644 (file)
--- a/openpower/sv/svp64_quirks.mdwn
+++ b/openpower/sv/svp64_quirks.mdwn
@@ -45,7 +45,34 @@ Power ISA has Condition Register Fields: how can element widths
 apply there? And branches: how can you have Saturation on something
 that does not return an arithmetic result? In short: there are actually
 four different categories (five including those for which Vectorisation
-makes no sense at all, such as `sc` or `mtmsr`).
+makes no sense at all, such as `sc` or `mtmsr`). The categories are:
+
+* arithmetic/logical including floating-point
+* Load/Store
+* Condition Register Field operations
+* branch
+
+Arithmetic (known as "normal" mode) is where Scalar and Parallel
+Reduction can be done: Saturation as well, and two new innovative
+modes for Vector ISAs: data-dependent fail-first and predicate result.
+Reduction and Saturation are common to see in Vector ISAs: it is just
+that they are usually added as explicit instructions. In SVP64 these
+concepts are applied in the abstract general form, which takes some
+getting used to, as it may result in invalid results, but ultimately
+it is critical to think in terms of the "rules", that everything is
+Scalar instructions in strict Program Order.
+
+Branch  is the one and only place where the Scalar
+(non-prefixed) operations differ from the Vector (element)
+instructions, as explained in a separate section.
+The
+RM bits can be used for other purposes because the Arithmetic modes
+make no sense at all for a Branch.
+Almost the entire
+SVP64 RM Field is interpreted differently from other Modes, in
+order to support a wide range of parallel boolean condition options
+which are expected of a Vector / GPU ISA. These save a considerable
+number of instructions in tight inner loop situations.
 
 # CR weird instructions