From: lkcl Date: Fri, 23 Sep 2022 12:35:33 +0000 (+0100) Subject: (no commit message) X-Git-Tag: opf_rfc_ls005_v1~322 X-Git-Url: https://git.libre-soc.org/?a=commitdiff_plain;h=e21ed997910a69ced301ddd9d96fc668f5986c5c;p=libreriscv.git --- diff --git a/openpower/sv/overview/discussion.mdwn b/openpower/sv/overview/discussion.mdwn index 49d7e9581..58486f7e1 100644 --- a/openpower/sv/overview/discussion.mdwn +++ b/openpower/sv/overview/discussion.mdwn @@ -2,3 +2,37 @@ * * + +# 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. +