From: lkcl Date: Sun, 9 Oct 2022 19:01:45 +0000 (+0100) Subject: (no commit message) X-Git-Tag: opf_rfc_ls005_v1~138 X-Git-Url: https://git.libre-soc.org/?a=commitdiff_plain;h=44173a372032b5d25eb5fe6c0cf536363a827f0c;p=libreriscv.git --- diff --git a/openpower/sv/rfc/ls002/discussion.mdwn b/openpower/sv/rfc/ls002/discussion.mdwn index 68e636c28..01b00a3de 100644 --- 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).)