(no commit message)
authorlkcl <lkcl@web>
Sun, 9 Oct 2022 21:26:45 +0000 (22:26 +0100)
committerIkiWiki <ikiwiki.info>
Sun, 9 Oct 2022 21:26:45 +0000 (22:26 +0100)
openpower/sv/rfc/ls002/discussion.mdwn

index 28b8a1ae9bbe14dd902a61b7d48bdfebc3c90f77..61d066db1d0ff74287de5c2f814fae0090aef6e7 100644 (file)
@@ -100,8 +100,16 @@ missed the addition to 1.6.1.6 (DX-Form).  TODO
    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:
 
@@ -109,8 +117,9 @@ 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