From d9d088b431372e176ffe09b17cd9e08286835f7a Mon Sep 17 00:00:00 2001 From: lkcl Date: Wed, 29 Mar 2023 22:45:59 +0100 Subject: [PATCH] --- openpower/sv/rfc/ls010.mdwn | 16 +++++++++++----- 1 file changed, 11 insertions(+), 5 deletions(-) diff --git a/openpower/sv/rfc/ls010.mdwn b/openpower/sv/rfc/ls010.mdwn index c93fb26be..b1320a732 100644 --- a/openpower/sv/rfc/ls010.mdwn +++ b/openpower/sv/rfc/ls010.mdwn @@ -124,12 +124,18 @@ To be absolutely clear: element numbering are expressed or implied ``` -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.** When exclusively using MSB0-numbering, SVP64 +Element offset +numbering is naturally **LSB0-sequentially-incrementing from zero, not +MSB0-incrementing** including when element-width overrides are used, +at which point the elements progress through each register +sequentially from the LSB end +(confusingly numbered the highest in MSB0 ordering) and progress +incrementally to the MSB end (confusingly numbered the lowest in +MSB0 ordering). + +When exclusively using MSB0-numbering, SVP64 becomes unnecessarily complex to both express and subsequently understand: -the required subtractions from 63, +the required conditional subtractions from 63, 31, 15 and 7 unfortunately become a hostile minefield, obscuring both intent and meaning. Therefore for the purposes of this section the more natural **LSB0 numbering is assumed** -- 2.30.2