(no commit message)

diff --git a/openpower/sv/rfc/ls002/discussion.mdwn b/openpower/sv/rfc/ls002/discussion.mdwn
index 68e636c28cb0a1f5a3ef571aceb2a91e56b3ee9d..01b00a3de71275b25528db722852b72942e4118b 100644 (file)
--- a/openpower/sv/rfc/ls002/discussion.mdwn
+++ b/openpower/sv/rfc/ls002/discussion.mdwn
@@ -2,3 +2,74 @@
 
 * [[sv/int_fp_mv]]
 
+# Questions (09 oct 2022)
+
+1. What is "BF16"?  It seems not to be mentioned in the architecture spec.
+   The architecture spec (VSX chapter) defines two 16-bit binary FP formats.
+   Judging by the way the RFC uses "BF16", I think it means what the VSX
+   chapter calls "bfloat16", which has the exponent in the same bits as
+   single format.  This should be clarified, and the corresponding format
+   will need to be defined in Section 4.3.1 (Data Format).
+2. For fishmv, what happens if the value supplied in the FPR is not
+   representable in single format?
+3. The first clause of the verbal description of fishmv seems to assume
+   that the contents of the specified register were produced by fmvis.
+   Is there any other use of fishmv?  If yes, the verbal description should
+   be generalized.  If no, the wording should be explicit about this use.
+4. The instruction names and mnemonics should be more consistent with the
+   architecture spec.  In particular, the architecture spec tends to use
+   "Move" for instructions that transfer data between registers.  Here are
+   two approaches.
+   a. Model the instructions on li (Load Immediate), an extended mnemonic for
+      addi.
+        fmvis --> Floating Load Immediate Single (flis)
+        fishmv --> Floating Load Immediate Single Lower (flisl)
+      Under this approach the new instructions would belong in their own
+      3-level section, after Section 4.6.4 (Floating-Point Load and Store
+      Double Pair Instructions).
+   b. Model the instructions on lxvkq (and the existing FP Load instructions)
+        fmvis --> Load Floating-Point Single Immediate (lfsi)
+        fishmv --> Load Floating-Point Single Immediate Lower (lfsil)
+      Under this approach the new instructions would belong in Section 4.6.2
+      (Floating-Point Load Instructions), with the Load Floating-Point
+      Single instructions.
+   I prefer (a), because I think it's confusing to treat these instructions,
+   which don't access storage, like instructions that do access storage.
+
+Other:
+
+1. The RFC should be based on the current version of the architecture,
+   which is V. 3.1B.  I believe this has no effect on the substance of the
+   RFC.  But it affects the identities of the instruction-list appendices,
+  which in V. 3.1B are E, F, G, and H.
+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).
+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
+   would supply the entire 32-bit FP single format value and avoid the need
+   for fishmv.  Why would you want a prefixed version of fishmv?
+4. The Motivation says "Even clearing an FPR to zero presently requires Load".
+   What about fsub FRT,FRA,FRA?
+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
+   fishmv the specified register is both source and target.  But "TX,T"
+   provides precedent for using the "target form" of register specification
+   for such cases.)
+6. The RTL for fmvis should use left arrow for assignment.
+7. The architecture spec (VSX chapter) uses "BFP32" and "BFP64", and the
+   lower-case versions thereof, for the 32-bit and 64-bit binary FP formats.
+   The RFC's "FP32" and "FP64" (and lower case of same) should be made
+   consistent with this usage.
+8. More generally, the style of the verbal description for both instructions
+   should be made more consistent with the style used in the architecture
+   spec.
+9. In the first clause of the verbal description of fishmv I think "inserted
+   into FRS" should be "inserted into the low-order half of the single-
+   format value corresponding to the contents of FRT".
+   A similar change should be made in the second sentence of the next
+   paragraph.
+10. The paragraph before the Programming Note in the fishmv description
+   says "This is strategically similar to how li combined with oris is used
+   to construct 32-bit Integers".  li combined with oris works only if bit 16
+   of the desired 32-bit integer is 0.  (A better way to construct a 32-bit
+   integer is to use pli (extended mnemonic for paddi).)