From ef8987b19391444ef0464e791171c3a069d1d943 Mon Sep 17 00:00:00 2001 From: lkcl Date: Fri, 21 Jul 2023 23:02:32 +0100 Subject: [PATCH] --- openpower/sv/rfc/ls012.mdwn | 17 ++++++++++++++++- 1 file changed, 16 insertions(+), 1 deletion(-) 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** -- 2.30.2