From f945b3c0f142154054a51ecf7aa2b42d0595b5fa Mon Sep 17 00:00:00 2001 From: lkcl Date: Sun, 25 Sep 2022 09:55:41 +0100 Subject: [PATCH] --- openpower/sv/overview/discussion.mdwn | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/openpower/sv/overview/discussion.mdwn b/openpower/sv/overview/discussion.mdwn index 484eefda3..c6838d30d 100644 --- a/openpower/sv/overview/discussion.mdwn +++ b/openpower/sv/overview/discussion.mdwn @@ -36,10 +36,13 @@ the register files is too great, and has chosen to require that, byte-ordered SRAM with elements to be accessed as if in a Little-Endian Software Environment. This does **not** impact Memory-ordering in any way and it does **not** impact arithmetic operations. + "Architecturally" is defined by Industry-standard convention to mean that how the Hardware is implemented is entirely down to the implementor, but that as far as *software* running on that hardware is concerned, -"Architecturally" everything appears as described. +"Architecturally" everything appears as described. Mathematics would +describe any given implementation and an Architecturally +correctly-defined specification as Topologically "Homeomorphic". In other words once loaded, software may be written that considers arithmetic values in a uniform environment regardless @@ -50,7 +53,8 @@ byte-level element-width override "Reverse Gear" element walking, or using Matrix REMAP with Dimensional Inversion, or any number of methods. -In the overview page is this: +In the overview page, where bytes are numbered in LSB0 order left +to right, is this: | byte0 | byte1 | byte2 | byte3 | byte4 | byte5 | byte6 | byte7 | | ----- | ----- | ----- | ----- | ----- | ----- | ----- | ----- | -- 2.30.2