From e56d4f427e03dc5af6b69ab67c8cb09c523aabfd Mon Sep 17 00:00:00 2001 From: lkcl Date: Thu, 22 Sep 2022 17:42:47 +0100 Subject: [PATCH] --- openpower/sv/svp64/appendix.mdwn | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/openpower/sv/svp64/appendix.mdwn b/openpower/sv/svp64/appendix.mdwn index fcdc45a1a..0e4eee6c4 100644 --- a/openpower/sv/svp64/appendix.mdwn +++ b/openpower/sv/svp64/appendix.mdwn @@ -656,11 +656,13 @@ Numbering relationships for CR fields are already complex due to being in BE format (*the relationship is not clearly explained in the v3.0B or v3.1 specification*). However with some care and consideration the exact same mapping used for INT and FP regfiles may be applied, -just to the upper bits, as explained below. The notation +just to the upper bits, as explained below. Firstly and most +importantly a new notation `CR{field number}` is used to indicate access to a particular Condition Register Field (as opposed to the notation `CR[bit]` which accesses one bit of the 32 bit Power ISA v3.0B -Condition Register) +Condition Register). + `CR{n}` refers to `CR0` when `n=0` and consequently, for CR0-7, is defined, in v3.0B pseudocode, as: @@ -670,6 +672,12 @@ For SVP64 the relationship for the sequential numbering of elements is to the CR **fields** within the CR Register, not to individual bits within the CR register. +This notation is designed to give *linear sequential +numbering* in the Vector domain on a straight sequential Vector Loop. +Without it, there is the risk of massive confusion as CR Fields +could be accessed in order `CR7 CR6 ... CR0 CR15 CR14 .. CR8 CR23..` +in Vector Loops. + In OpenPOWER v3.0/1, BF/BT/BA/BB are all 5 bits. The top 3 bits (0:2) select one of the 8 CRs; the bottom 2 bits (3:4) select one of 4 bits *in* that CR (EQ/LT/GT/SO). The numbering was determined (after 4 months of -- 2.30.2