From 3f006c6d9f6808b2400ac475c104bb31bc5c9510 Mon Sep 17 00:00:00 2001 From: lkcl Date: Wed, 29 Mar 2023 19:03:32 +0100 Subject: [PATCH] --- openpower/sv/rfc/ls010.mdwn | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/openpower/sv/rfc/ls010.mdwn b/openpower/sv/rfc/ls010.mdwn index 750452b62..180591001 100644 --- a/openpower/sv/rfc/ls010.mdwn +++ b/openpower/sv/rfc/ls010.mdwn @@ -129,12 +129,13 @@ sequential 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.** Expressed exclusively in MSB0-numbering, SVP64 is +MSB0-incrementing.** When exclusively using MSB0-numbering, SVP64 becomes unnecessarily complex to both express and subsequently understand: the required subtractions from 63, -31, 15 and 7 unfortunately become a hostile minefield. Therefore for the +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** -and it is up to the reader to translate to MSB0 numbering. +and it is left to the reader to translate to MSB0 numbering. The Canonical specification for how element-sequential numbering and element-width overrides is defined is expressed in the following c -- 2.30.2