for fishmv. Why would you want a prefixed version of fishmv?
**
+the more interesting initial question is, "why no `pflis`?" and
+the answer to that is "because flis and fishmv do exactly the same
+job in exactly the same amount of bits" (64).
+`flis` fills in a BF16, `fishmv` extends to an FP32,
+and `pflis` would fill in an FP32 in exactly the same amount
+of space, making it a redundant encoding. this just leaves the
+purpose of `pfishmv` to be to extend (fill) an FP32 out to an FP64.
+
the analysis counting instructions and D-Cache Loads actually shows
-that whilst the initial idea for `pfmvis` would be to fill in the
+that whilst the initial idea for `pfishmv` would be to fill in the
remaining mantissa and high exponent bits to complete a full FP64,
the cost of doing so is:
* 1x32 fishmv
* 1x64 pfishmv
-which totals to 16 bytes loaded which is actually *more* than just `lfd`,
-which is only 4 + 8 bytes. the only technical reason therefore is
+which totals QTY 4of 32-bits (across I-Cache) which is actually *more* than just `lfd`,
+which is only QTY 3of 32-bits (across both I-Cache and D-Cache).
+the only technical reason therefore is
to avoid D-Cache entirely, just like the 5-instruction sequence
that writes a 64-bit GPR only from immediates
(li, oris, rldicl, li, oris) although that is justifiable