From a0967d9d6401b24b8e41e0dd37ea0e6a5dd002b5 Mon Sep 17 00:00:00 2001
From: lkcl <lkcl@web>
Date: Sun, 9 Oct 2022 20:30:14 +0100
Subject: [PATCH]

---
 openpower/sv/rfc/ls002/discussion.mdwn | 33 ++++++++++++++++++++++++++
 1 file changed, 33 insertions(+)

diff --git a/openpower/sv/rfc/ls002/discussion.mdwn b/openpower/sv/rfc/ls002/discussion.mdwn
index 1087729ed..e73943ca4 100644
--- a/openpower/sv/rfc/ls002/discussion.mdwn
+++ b/openpower/sv/rfc/ls002/discussion.mdwn
@@ -18,10 +18,14 @@
    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
@@ -44,41 +48,70 @@
 
    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).)
+**
-- 
2.30.2