(no commit message)
authorlkcl <lkcl@web>
Sat, 24 Sep 2022 20:19:25 +0000 (21:19 +0100)
committerIkiWiki <ikiwiki.info>
Sat, 24 Sep 2022 20:19:25 +0000 (21:19 +0100)
openpower/sv/overview/discussion.mdwn

index 8eebff62c55f5b9284ece2afa646ffd5fb43603d..b4287ba28979c2414d84953eb013edaa646d4d36 100644 (file)
@@ -5,6 +5,38 @@
 
 # BE Regfile confusion
 
+Defining how an element-addressable variable-width regfile is to
+be accessed is exceptionally difficult to pin down when conventions
+are used that start MSB numbering from zero (MSB0) rather than at the
+Industry-standard convention, LSB0.  The confusion arises from the
+possibility of MSB0 numbering being potentially applicable to:
+
+* bits
+* bytes
+* register numbers
+* element numbers
+
+Then there is the completely separate issue of whether:
+
+* Memory should be the sole location where LE/BE byteswapping should
+  be applicable, Architecturally
+* Both the register file *and* Memory are, both, Architecturally,
+  LE/BE reorderable and thus **direct and explicit** control over
+  reordering over Memory **and the bytes inside regfile data**
+  is provided at the ISA Level.
+
+Simple-V has made the decision that providing programmers with explicit
+control over the byte-ordering when data is transferred in and out of
+the register files is too great, and has chosen to require that,
+**Architecturally**, the register file is to be treated as a Little-Endian
+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.
+
 In the overview page is this:
 
        | byte0 | byte1 | byte2 | byte3 | byte4 | byte5 | byte6 | byte7 |