(no commit message)

diff --git a/openpower/sv/svp64_quirks.mdwn b/openpower/sv/svp64_quirks.mdwn
index 26d9663250f37a3e2b3446d7550213b0398dece2..bff45dcd8b209c7339b4bc408eb613ded4c2051e 100644 (file)
--- a/openpower/sv/svp64_quirks.mdwn
+++ b/openpower/sv/svp64_quirks.mdwn
@@ -685,3 +685,29 @@ complexity in the Hazard Management when context-switching CR fields, as the
 entire batch of 128 CR Fields may be transferred to 8 GPRs with a VL of 16
 and elwidth overriding of 32. Truncation is sufficent, dropping the top 32 bits
 of the Condition Register(s) which are always zero anywy.
+
+# Separate Scalar and Vector Condition Register files
+
+As explained in the introduction [[sv/svp64]] and [[sv/cr_ops]]
+Scalar Power ISA lacks "Conditional Execution" present in ARM
+Scalar ISA of several decades.  When Vectorised the fact that
+Rc=1 Vector results can immediately be used as a Predicate Mask
+back into the following instruction can result in large latency
+unless "Vector Chaining" is used in the Micro-Architecture.
+
+But that aside is not the main problem faced by the introduction
+of Simple-V to the Power ISA: it's that the existing implementations
+(IBM) don't have "Conditional Execution" and to add it to their
+existing designs would be too disruptive a first step.
+
+A compromise is to wipe blank certain entries in the Register Dependency
+Matrices by prohibiting some operations involving the two groups
+of CR Fields: those that fall into the existing Scalar 32-bit CR
+(fields CR0-CR7) and those that fall into the newly-introduced
+CR Fields, CR8-CR127.
+
+This will drive compiler writers nuts, and give assembler writers headaches,
+but it gives IBM the opportunity to implement SVP64 without massive
+disruption. They can add an entirely new Vector CR register file,
+new pipelines etc safe in the knowledge that existing Scalar HDL
+needs no modification.