From: lkcl Date: Sun, 9 Oct 2022 20:07:05 +0000 (+0100) Subject: (no commit message) X-Git-Tag: opf_rfc_ls005_v1~129 X-Git-Url: https://git.libre-soc.org/?a=commitdiff_plain;h=e6616dd6589b8acd1b57b1d2c7c267b5cbae74d0;p=libreriscv.git --- diff --git a/openpower/sv/rfc/ls002/discussion.mdwn b/openpower/sv/rfc/ls002/discussion.mdwn index 4f9a9b380..102bbebb3 100644 --- a/openpower/sv/rfc/ls002/discussion.mdwn +++ b/openpower/sv/rfc/ls002/discussion.mdwn @@ -22,7 +22,9 @@ BF16 seems to be an equally commonly used term for bfloat16, yes. 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`. +`fmvis`. these are immediates, statically-compiled. if the developer +wants "invalid" data, statically-compiled into a binary, it is reasonable +to assume they have good reasons for doing so. ** 3. The first clause of the verbal description of fishmv seems to assume @@ -33,7 +35,9 @@ value: nothing. if `fld` raised flags or exceptions then so would (should) 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. +be a different matter: temporary storage for constants to be transferred +directly (unmodified) to GPRs for example. but DOUBLE() formatting +makes that not possible unfortunately. ** 4. The instruction names and mnemonics should be more consistent with the