(no commit message)

diff --git a/openpower/sv/rfc/ls012.mdwn b/openpower/sv/rfc/ls012.mdwn
index a5a2791e5748410cdeddf2de63f69b6884d07d1c..7379aa2776a3e6ab59a37d0364ec781280dd6ffb 100644 (file)
--- a/openpower/sv/rfc/ls012.mdwn
+++ b/openpower/sv/rfc/ls012.mdwn
@@ -561,6 +561,20 @@ in-register algorithms reducing the number of registers needed and
 thus saving power due to making the *overall* algorithm more efficient,
 as opposed to micro-focussing on a localised power increase.
 
+As a general rule of thumb, though:
+
+* going beyond 3-in 2-out is an extremely bad idea
+* 3-in 2-out is extreme borderline (including Condition Codes)
+* 3-in 1-out needs really good justification
+* 2-in 1-out (or 2-in 2-out if one is a Condition Code or Status Register)
+  is acceptable
+
+Remember to include all Register Files (Status Registers,
+Condition Fields) in the assessment: each register will
+need its own Hazard Protection, and in an Out-of-Order
+system that results in significant resource utilisation
+in silicon.
+
 **How many register files does it use?**
 
 Complex instructions pulling in data from multiple register files can
@@ -568,7 +582,8 @@ create unnecessary issues surrounding Dependency Hazard Management in
 Out-of-Order systems.  As a general rule it is better to keep complex
 instructions reading and writing to the same register file, relying
 on much simpler (1-in 1-out) instructions to transfer data between
-register files.
+register files.  This rule-of-thumb allows the Dependency Matrices
+to be made sparse or significantly reduced in both row and column entries.
 
 **Can other existing instructions (plural) do the same job**