(no commit message)
authorlkcl <lkcl@web>
Sun, 25 Sep 2022 00:15:05 +0000 (01:15 +0100)
committerIkiWiki <ikiwiki.info>
Sun, 25 Sep 2022 00:15:05 +0000 (01:15 +0100)
openpower/sv/overview/discussion.mdwn

index 525f8c22dd025003911b8164ab68b95c5333db60..8398c8663917a37020a862229673f3eabce1dcb1 100644 (file)
@@ -199,7 +199,9 @@ asuming a Little-Endian system, in the c programming language:
     elreg_t int_regfile[128];
 
 Where things become complicated is how to transliterate the above into
-MSB0 numbering.  We start with some definitions:
+MSB0 numbering, which significantly harms understanding and thus requires
+very careful, comprehensive and explicit coverage.
+We start with some definitions:
 
 * bit-ordering below is in MSB0 order, prefix "b"
 * byte-ordering is in MSB0 order, prefix "B"
@@ -266,14 +268,20 @@ same results as above:
 Next, elements are introduced.  Using the definition `int_regfile` above
 let us perform two operations:
 
-    int_regfile[2].s[1] = 1<<3
-    int_regfile[2].s[4] = 1<<9
-    RA = GPR(2)
-    RB = GPR(3)
+    int_regfile[2].s[1] = 1<<3 # e1 in the element numbering definition
+    int_regfile[2].s[4] = 1<<9 # e4 in the same definition, above
+    RA = GPR(2) # r2 in the register numbering-definition, above
+    RB = GPR(3) # r3, again, same numbering definition
 
 Examining the contents of RA is found to be:
 
-    RA.H0 = 0x0000  RA.H1 = 0x0000  RA.H2 = 0x0008   RA.H3 = 0x0000
-    RB.H0 = 0x0000  RB.H1 = 0x0000  RB.H2 = 0x0008   RB.H3 = 0x0100
+    RA.H0 = 0x0000  RA.H1 = 0x0000  RA.H2 = 0x0008  RA.H3 = 0x0000
+    RA = 0x0000_0000_0008_0000
+    RB.H0 = 0x0000  RB.H1 = 0x0000  RB.H2 = 0x0000  RB.H3 = 0x0200
+    RA = 0x0000_0000_0000_0200
 
-The reason
+The reason why **GPR(3)** contains the value 0x200 (1<<9) when 
+it was the 2nd Vector Element being written to is because of
+the sequential conceptual overlap between **all** registers, as
+ultimately the regfile must be considered arbitrarily-byte-addressable
+just like any Memory.