From: lkcl <lkcl@web>
Date: Sun, 9 Oct 2022 21:26:45 +0000 (+0100)
Subject: (no commit message)
X-Git-Tag: opf_rfc_ls005_v1~123
X-Git-Url: https://git.libre-soc.org/?a=commitdiff_plain;h=d93adc1975ffc05ffd3149d875be0e9416819504;p=libreriscv.git

---

diff --git a/openpower/sv/rfc/ls002/discussion.mdwn b/openpower/sv/rfc/ls002/discussion.mdwn
index 28b8a1ae9..61d066db1 100644
--- a/openpower/sv/rfc/ls002/discussion.mdwn
+++ b/openpower/sv/rfc/ls002/discussion.mdwn
@@ -100,8 +100,16 @@ missed the addition to 1.6.1.6 (DX-Form).  TODO
    for fishmv.  Why would you want a prefixed version of fishmv?
 **
 
+the more interesting initial question is, "why no `pflis`?" and
+the answer to that is "because flis and fishmv do exactly the same
+job in exactly the same amount of bits" (64).
+`flis` fills in a BF16, `fishmv` extends to an FP32,
+and `pflis` would fill in an FP32 in exactly the same amount
+of space, making it a redundant encoding.  this just leaves the
+purpose of `pfishmv` to be to extend (fill) an FP32 out to an FP64.
+
 the analysis counting instructions and D-Cache Loads actually shows
-that whilst the initial idea for `pfmvis` would be to fill in the
+that whilst the initial idea for `pfishmv` would be to fill in the
 remaining mantissa and high exponent bits to complete a full FP64,
 the cost of doing so is:
 
@@ -109,8 +117,9 @@ the cost of doing so is:
 * 1x32 fishmv
 * 1x64 pfishmv
 
-which totals to 16 bytes loaded which is actually *more* than just `lfd`,
-which is only 4 + 8 bytes.  the only technical reason therefore is
+which totals QTY 4of 32-bits (across I-Cache) which is actually *more* than just `lfd`,
+which is only QTY 3of 32-bits (across both I-Cache and D-Cache).
+the only technical reason therefore is
 to avoid D-Cache entirely, just like the 5-instruction sequence
 that writes a 64-bit GPR only from immediates
 (li, oris, rldicl, li, oris) although that is justifiable