From 132981769d9e2be626337fda10bb567efb0932fb Mon Sep 17 00:00:00 2001 From: lkcl Date: Wed, 29 Mar 2023 15:23:04 +0100 Subject: [PATCH] --- openpower/sv/rfc/ls010.mdwn | 18 +++++++++++++----- 1 file changed, 13 insertions(+), 5 deletions(-) diff --git a/openpower/sv/rfc/ls010.mdwn b/openpower/sv/rfc/ls010.mdwn index b3971fc94..83de11496 100644 --- a/openpower/sv/rfc/ls010.mdwn +++ b/openpower/sv/rfc/ls010.mdwn @@ -49,16 +49,18 @@ interoperability expectations within certain environments. In the Upper Compliancy Levels the size of the GPR and FPR Register files are expanded from 32 to 128 entries, and the number of CR Fields expanded from CR0-CR7 to CR0-CR127. + Memory access remains exactly the same: the effects of `MSR.LE` remain exactly the same, -affecting **only** the Load and Store memory-register operation byte-order, -and having nothing to do with the +affecting as they already do and remain to **only** the Load and Store memory-register +operation byte-order, and having nothing to do with the ordering of the contents of register files or register-register operations. Whilst the bits within the GPRs and FPRs are expected to be MSB0-ordered and for numbering to be sequentially incremental the element offset numbering is naturally -**LSB0-sequentially-incrementing from zero not MSB0-incrementing.** Expressed in -MSB0-numbering SVP64 is unnecessarily complex to understand: subtractions from 63, 31, -15 and 7 become a hostile minefield. Therefore for the purposes of this section +**LSB0-sequentially-incrementing from zero not MSB0-incrementing.** Expressed exclusively in +MSB0-numbering, SVP64 is unnecessarily complex to understand: the required +subtractions from 63, 31, 15 and 7 unfortunately become a hostile minefield. +Therefore for the purposes of this section the more natural **LSB0 numbering is assumed** and it is up to the reader to translate to MSB0 numbering. The Canonical specification for how element-sequential numbering and element-width @@ -77,6 +79,12 @@ is inherently LSB0: } el_reg_t; elreg_t int_regfile[128]; + + void get_register_element(el_reg_t* el, int gpr, int element, int width) { + switch (width) { + case 64: el->l = int_regfile[gpr].l[element]; + } + } ``` Example add operation implementation when elwidths are 64-bit: -- 2.30.2