From: lkcl <lkcl@web>
Date: Fri, 21 Jul 2023 22:02:32 +0000 (+0100)
Subject: (no commit message)
X-Git-Url: https://git.libre-soc.org/?a=commitdiff_plain;h=ef8987b19391444ef0464e791171c3a069d1d943;p=libreriscv.git

---

diff --git a/openpower/sv/rfc/ls012.mdwn b/openpower/sv/rfc/ls012.mdwn
index a5a2791e5..7379aa277 100644
--- 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**