From 315cfdb906e073ef61ca71a00713163b895c6cb8 Mon Sep 17 00:00:00 2001
From: Luke Kenneth Casson Leighton <lkcl@lkcl.net>
Date: Tue, 18 Apr 2023 16:30:22 +0100
Subject: [PATCH] add extsb/h/w example of XLEN see
 https://bugs.libre-soc.org/show_bug.cgi?id=1061 and
 https://bugs.libre-soc.org/show_bug.cgi?id=988

---
 openpower/sv/rfc/ls005.mdwn | 70 +++++++++++++++++++++++++++++++++++++
 1 file changed, 70 insertions(+)

diff --git a/openpower/sv/rfc/ls005.mdwn b/openpower/sv/rfc/ls005.mdwn
index b2981600c..6dd666ad9 100644
--- a/openpower/sv/rfc/ls005.mdwn
+++ b/openpower/sv/rfc/ls005.mdwn
@@ -164,6 +164,10 @@ do i = 0 to ((XLEN/8)-1)
    RA[(i*8):(i*8)+7] <-  n
 ```
 
+Here as the instruction's intent is to count bytes, and RA contains on
+a per-byte basis a SIMD-style count of each byte's 1s, it becomes possible
+to simply count less bytes.
+
 ## no modification needed, but function changes
 
 For the `addi` instruction there is no apparent change:
@@ -229,6 +233,72 @@ When XLEN=8 "half register width" is clearly 4 bit, thus the LSB nibble is teste
 but still sign-extended for comparison
 against the 16-bit signed immediate.
 
+## Extend Sign byte/half/word
+
+This instruction can be redefined again in terms of:
+
+* "Word" meaning "Half of register width"
+* "Half-word" meaning "Quarter of register width"
+* "Byte" meaning "One-eighth of register width"
+
+And a table results as follows:
+
+```
+    XLEN=8:
+                extsb: 1-bit -> 8-bit sign extension
+                extsh: 2-bit -> 8-bit sign extension
+                extsw: 4-bit -> 8-bit sign extension
+    XLEN=16:
+                extsb: 2-bit -> 16-bit sign extension
+                extsh: 4-bit -> 16-bit sign extension
+                extsw: 8-bit -> 16-bit sign extension
+    XLEN=32:
+                extsb: 4-bit -> 32-bit sign extension
+                extsh: 8-bit -> 32-bit sign extension
+                extsw: 16-bit -> 32-bit sign extension
+    XLEN=64:
+                extsb: 8-bit -> 64-bit sign extension
+                extsh: 16-bit -> 64-bit sign extension
+                extsw: 32-bit -> 64-bit sign extension
+```
+
+If the instructions were kept as presently defined then there
+is a loss of functionality and opportunity:
+
+```
+    XLEN=8: # completely wasted opportunity
+                extsb: 8-bit  -> 8-bit does nothing
+                extsh: 16-bit -> 8-bit truncates
+                extsw: 32-bit -> 8-bit truncates
+    XLEN=16: # wasted 2/3 of encoding
+                extsb: 8-bit  -> 16-bit sign extension
+                extsh: 16-bit -> 16-bit does nothing
+                extsw: 32-bit -> 16-bit truncates
+    XLEN=32: # wasted 1/3 of encoding
+                extsb: 8-bit  -> 32-bit sign extension
+                extsh: 16-bit -> 32-bit sign extension
+                extsw: 32-bit -> 32-bit does nothing
+    XLEN=64: # unchanged (default) behaviour
+                extsb: 8-bit  -> 64-bit sign extension
+                extsh: 16-bit -> 64-bit sign extension
+                extsw: 32-bit -> 64-bit sign extension
+```
+
+The RTL for `extsb` becomes:
+
+```
+    in <- (RA)[XLEN-8:XLEN-1]
+    if XLEN = 8  then RT <- in[0]]  * 8               # 1->8
+    if XLEN = 16 then RT <- in[13]] * 15 || in[15]    # 2->16
+    if XLEN = 32 then RT <- in[28]] * 29 || in[29:31] # 4->32
+    if XLEN = 64 then RT <- in[55]] * 56 || in[57:63] # 8->64
+```
+
+And `extsh` and `extsw` follow similar logic. Interestingly there is
+no loss of functionality compared to keeping `extsb` always as "byte
+sign-extending" and ironically the loss of opportunity *is* to keep
+`extsb` the same regardless of XLEN.
+
 \newpage{}
 
 [[!tag opf_rfc]]
-- 
2.30.2