(no commit message)

diff --git a/openpower/sv/rfc/ls002/discussion.mdwn b/openpower/sv/rfc/ls002/discussion.mdwn
index 9259ff0cb9e3a41f76a40bc117c23b62e2217816..07e147751e75a1d2744b9a2dc770b71b8e87155d 100644 (file)
--- a/openpower/sv/rfc/ls002/discussion.mdwn
+++ b/openpower/sv/rfc/ls002/discussion.mdwn
@@ -23,6 +23,10 @@ BF16 seems to be an equally commonly used term for bfloat16, yes.
 I'm assuming you're asking what happens if something like `f3 = 0x0080_0000_0000_0001` and `fishmv f3, 0xABCD` is executed:
 Exactly the same thing as if the FPR value isn't representable in f32 format for stfs -- the value stored is defined by the `SINGLE` pseudo-code function, no fp status bits are set. Likewise, the input f32 value for fishmv is determined by the `SINGLE` pseudo-code function, no fp status bits are set, fishmv then replaces the lower 16 bits of the f32 value with the immediate, then converts the resulting f32 back to f64 using `DOUBLE` and stores it in FRT.
 
+Ultimately, 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
    that the contents of the specified register were produced by fmvis.
@@ -36,6 +40,12 @@ 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.
 
+however alternative uses by programmers cannot be ruled out. it may
+be the case that despite the format being DOUBLE() there is in fact
+an FPR->GPR transfer instruction that can at least get the 32-bits
+of immediate back out as a contiguous undamaged block.  thus adding
+notes that may turn out to be restrictive is inadviseable.
+
 **
 4. The instruction names and mnemonics should be more consistent with the
    architecture spec.  In particular, the architecture spec tends to use