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

---

diff --git a/openpower/sv/rfc/ls002/discussion.mdwn b/openpower/sv/rfc/ls002/discussion.mdwn
index e73943ca4..247fdf7f4 100644
--- a/openpower/sv/rfc/ls002/discussion.mdwn
+++ b/openpower/sv/rfc/ls002/discussion.mdwn
@@ -13,11 +13,17 @@
    will need to be defined in Section 4.3.1 (Data Format).
 **
 
+BF16 seems to be an equally commonly used term for bfloat16, yes.
+
 **
 2. For fishmv, what happens if the value supplied in the FPR is not
    representable in single format?
 **
 
+exactly the same thing as if `fld` were used to load an "unrepresentable"
+value: nothing.  if `fld` raised flags or exceptions then so would (should)
+`fmvis`.
+
 **
 3. The first clause of the verbal description of fishmv seems to assume
    that the contents of the specified register were produced by fmvis.
@@ -25,6 +31,10 @@
    be generalized.  If no, the wording should be explicit about this use.
 **
 
+given that the bits are spread out in `DOUBLE()` format it seems unlikely.
+if the bits were placed contiguously (sequentially) then it would indeed
+be a different matter.
+
 **
 4. The instruction names and mnemonics should be more consistent with the
    architecture spec.  In particular, the architecture spec tends to use
@@ -50,7 +60,13 @@
    which don't access storage, like instructions that do access storage.
 **
 
-**
+the fact that they bypass D-Cache and correspondingly raise no flags or
+exceptions is the connection to `ld`.  despite that i like (a) as well
+although for purely non-technical reasons, more "memorable", i do love
+the two mnemonics `flis fishmv` :)
+
+we picked "s" on the end of `fmvis` (`flis`) because it is "shifted"
+(like `oris`)
 
 Other:
 
@@ -61,11 +77,15 @@ Other:
   which in V. 3.1B are E, F, G, and H.
 **
 
+ackniwledged.  will edit
+
 **
 2. Additional affected sections are 1.6.1.6 (additional line for DX-form),
    1.6.2 (additional use for d0,d1,d2), and Appendix D (Opcode Maps).
 **
 
+ditto
+
 **
 3. Does the last line of the Summary apply to both instructions or just to
    fishmv?  I can see why you would want a prefixed version of fmvis, which
@@ -73,11 +93,29 @@ Other:
    for fishmv.  Why would you want a prefixed version of fishmv?
 **
 
+the analysis counting instructions and D-Cache Loads actually shows
+that whilst the initial idea for `pfmvis` would be to fill in the
+remaining mantissa and high exponent bits to complete a full FP64,
+the cost of doing so is:
+
+* 1x32 flis
+* 1x32 fishmv
+* 1x64 pfishmv
+
+which is QTY 8 bytes which is actually *more* than just `fld`,
+which is only QTY 6 bytes.  the only technical reason therefore
+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)
+
 **
 4. The Motivation says "Even clearing an FPR to zero presently requires Load".
    What about fsub FRT,FRA,FRA?
 **
 
+didn't know about it! although technically that reads registers
+(unless micro-code-redirected to an internal zeroing operation)
+
 **
 5. "FRS" for both instructions should be changed to "FRT".  ("FRS" normally
    specifies a source register; see Section 1.6.2.  I understand that for