* <http://lists.libre-soc.org/pipermail/libre-soc-dev/2020-December/001742.html>
* <http://lists.libre-soc.org/pipermail/libre-soc-dev/2020-December/001748.html>
+
+# BE Regfile confusion
+
+In the overview page is this:
+
+ | byte0 | byte1 | byte2 | byte3 | byte4 | byte5 | byte6 | byte7 |
+ | ----- | ----- | ----- | ----- | ----- | ----- | ----- | ----- |
+ r0 | b[0] | b[1] | b[2] | b[3] | b[4] | b[5] | b[6] | b[7] |
+ r1 | b[8] | b[9] | b[10] | b[11] | b[12] | b[13] | b[14] | b[15] |
+
+Starting an elwidth=16 loop from r0 and extending for
+7 elements would begin at r0 and extend partly over r1. Note that
+b0 indicates the low byte (lowest 8 bits) of each 16-bit word, and
+b1 represents the top byte:
+
+ | byte0 | byte1 | byte2 | byte3 | byte4 | byte5 | byte6 | byte7 |
+ | ----- | ----- | ----- | ----- | ----- | ----- | ----- | ----- |
+ r0 | s[0].b0 b1 | s[1].b0 b1 | s[2].b0 b1 | s[3].b0 b1 |
+ r1 | s[4].b0 b1 | s[5].b0 b1 | s[6].b0 b1 | unmodified |
+
+If data is loaded at elwidth=16 as above, then accessed as elwidth=8,
+then in order to get at it in an arithmetically-expected order of
+lowest byte first followed by highest byte, would require this ordering:
+
+ | byte0 | byte1 | byte2 | byte3 | byte4 | byte5 | byte6 | byte7 |
+ | ----- | ----- | ----- | ----- | ----- | ----- | ----- | ----- |
+ r0 | b[1] | b[0] | b[3] | b[2] | b[5] | b[4] | b[7] | b[6] |
+
+Whilst this is technically possible to do (with 2D REMAP) it is not
+reasonable to "punish" BE developers by forcing them into the
+situation of having to perform such element-level reordering, nor
+is it reasonable for the complexity to bleed over into LE Mode
+in order to "compensate" by making BE easier but LE more difficult.
+