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"
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.