(no commit message)
[libreriscv.git] / openpower / sv / cr_ops.mdwn
index 1da2cc3a10caf09262e56d7f7144cc3112cc002c..cae386c2d03b39c5c7568af44908630bf12a7191 100644 (file)
@@ -18,7 +18,7 @@ interesting conceptual challenges for SVP64, which was designed
 primarily for vectors of arithmetic and logical operations. However
 if predicates may be bits of CR Fields it makes sense to extend
 Simple-V to cover CR Operations, especially given that Vectorised Rc=1
-may be processed by Vectorised CR Operations tbat usefully in turn
+may be processed by Vectorised CR Operations that usefully in turn
 may become Predicate Masks to yet more Vector operations, like so:
 
 ```
@@ -51,6 +51,8 @@ by [[sv/normal]].
 * Examples to which this section does **not** apply include
   `fadds.` and `subf.` which both produce arithmetic results
   (and a CR Field co-result).
+* `mtcr` is considered [[openpower/sv/normal]] because it refers
+  to the entire 32-bit Condition Register rather than to CR Fields.
 
 The CR Mode Format still applies to `sv.cmpi` because despite
 taking a GPR as input, the output from the Base Scalar v3.0B `cmpi`
@@ -73,12 +75,12 @@ Field result *is* the main result.
 
 SVP64 RM `MODE` (includes `ELWIDTH_SRC` bits) for CR-based operations:
 
-|6 | 7 |19-20|  21 | 22   23 |  description     |
-|--|---|-----| --- |---------|----------------- |
-|/ | / |0 RG |   0 | dz  sz  | simple mode                      |
-|/ | / |0 RG |   1 | dz  sz  | scalar reduce mode (mapreduce) |
-|zz|SNZ|1 VLI| inv |  CR-bit | Ffirst 3-bit mode      |
-|/ |SNZ|1 VLI| inv |  dz sz  | Ffirst 5-bit mode (implies CR-bit from result) |
+|6 | 7 |19:20|21 | 22:23   |  description     |
+|--|---|-----|---|---------|------------------|
+|/ | / |RG 0 | 0 | dz  sz  | simple mode                      |
+|/ | / |RG 0 | 1 | dz  sz  | scalar reduce mode (mapreduce) |
+|zz|SNZ|VLI 1|inv|  CR-bit | Ffirst 3-bit mode      |
+|/ |SNZ|VLI 1|inv|  dz sz  | Ffirst 5-bit mode (implies CR-bit from result) |
 
 Fields:
 
@@ -90,8 +92,8 @@ Fields:
   SNZ=1 a value "1" is put in place of "0".
 * **inv CR-bit** just as in branches (BO) these bits allow testing of
   a CR bit and whether it is set (inv=0) or unset (inv=1)
-* **RG** inverts the Vector Loop order (VL-1 downto 0) rather
-  than the normal 0..VL-1
+* **RG** Reverse-Gear: inverts the Vector Loop order (VL-1 downto 0) rather
+  than the normal 0 upto VL-1
 * **SVM** sets "subvector" reduce mode
 * **VLi** VL inclusive: in fail-first mode, the truncation of
   VL *includes* the current element at the failure point rather
@@ -194,12 +196,16 @@ result to zero, and also all subsequent CR Field elements thereafter:
 
 `sv.crxor` with reduction would be particularly useful for parity
 calculation for example, although there are many ways in which the same
-calculation could be carried out after transferring a vector of CR Fields
+calculation could be carried out (`parityw`)
+after transferring a vector of CR Fields
 to a GPR using crweird operations.
 
 Implementations are free and clear to optimise these reductions in any way
 they see fit, as long as the end-result is compatible with Strict Program
 Order being observed, and Interrupt latency is not adversely impacted.
+Good examples include `sv.cror/mr` which is a cumulative ORing of
+a Vector of CR Field bits, and consequently an easy target for
+parallelising.
 
 ## Unusual and quirky CR operations
 
@@ -212,7 +218,7 @@ Order being observed, and Interrupt latency is not adversely impacted.
     cmpeqb BF,RA,RB
 ```
 
-With `ELWIDTH` applying to the source GPR operands this is perfectly fine.
+With `ELWIDTH` applying to the source GPR operands this is perfectly fine. 
 
 **crweird operations**
 
@@ -229,6 +235,36 @@ The "weird" operations have a non-standard behaviour, being able to
 treat *individual bits* of a GPR effectively as elements.  They are
 expected to be Micro-coded by most Hardware implementations.
 
+## Effectively-separate Vector and Scalar Condition Register file
+
+As mentioned in the introduction on [[sv/svp64]] some prohibitions
+are made on instructions involving Condition Registers that allow
+implementors to actually consider the Scalar CR (fields CR0-CR7)
+as a completely separate register file from the Vector CRs
+(fields CR8-CR127).
+
+The complications arise for existing Hardware implementations
+due to Power ISA not having had "Conditional Execution" added.
+Adding entirely new pipelines and a new Vector CR Register file
+is a much easier proposition to consider.
+
+The prohibitions utilise the CR Field numbers implicitly to
+split out Vectorised CR operations to be considered completely
+separare and distinct from Scalar CR operations *even though
+they both use the same binary encoding*.  This does in turn
+mean that at the Decode Phase it becomes necessary to examine
+not only the operation (`sv.crand`, `sv.cmp`) but also
+the CR Field numbers as well as whether, in the EXTRA2/3 Mode
+bits, the operands are Vectorised.
+
+A future version of Power ISA, where SVP64Single is proposed,
+would in fact introduce "Conditional Execution", including
+for VSX.  At which point this prohibition becomes moot as
+Predication would be required to be added into the existing
+Scalar (and PackedSIMD VSX) side of existing Power ISA
+implementations.
+
+
 --------
 
 [[!tag standards]]