From d93adc1975ffc05ffd3149d875be0e9416819504 Mon Sep 17 00:00:00 2001 From: lkcl Date: Sun, 9 Oct 2022 22:26:45 +0100 Subject: [PATCH] --- openpower/sv/rfc/ls002/discussion.mdwn | 15 ++++++++++++--- 1 file changed, 12 insertions(+), 3 deletions(-) diff --git a/openpower/sv/rfc/ls002/discussion.mdwn b/openpower/sv/rfc/ls002/discussion.mdwn index 28b8a1ae9..61d066db1 100644 --- a/openpower/sv/rfc/ls002/discussion.mdwn +++ b/openpower/sv/rfc/ls002/discussion.mdwn @@ -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 -- 2.30.2