* register numbers
* element numbers
+In other words, when communicating in a Specification there are **four**
+possible areas for confusion.
+
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
+ be applicable, Architecturally.
+* Both the register file *and* Memory should both be, Architecturally,
+ LE/BE reorderable with the implication that
+ **direct and explicit** control over
reordering over Memory **and the bytes inside regfile data**
- is provided at the ISA Level.
+ needs 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
but that as far as *software* running on that hardware is concerned,
"Architecturally" everything appears as described.
+In other words once loaded, software may be written that
+considers arithmetic values in a uniform environment regardless
+of whether `MSR.BE`, which is considered to affect **Memory only**,
+is set or unset. If byteswapping is required it may be performed
+explicitly, by either loading to/from Memory or by performing Simple-V
+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:
| byte0 | byte1 | byte2 | byte3 | byte4 | byte5 | byte6 | byte7 |