From: lkcl Date: Sun, 20 Dec 2020 00:49:06 +0000 (+0000) Subject: (no commit message) X-Git-Tag: convert-csv-opcode-to-binary~1147 X-Git-Url: https://git.libre-soc.org/?a=commitdiff_plain;h=af9b827420496cd79e3185f70b51abe679a61f05;p=libreriscv.git --- diff --git a/openpower/sv/svp_rewrite/svp64.mdwn b/openpower/sv/svp_rewrite/svp64.mdwn index c8dfc1a9e..6189eef07 100644 --- a/openpower/sv/svp_rewrite/svp64.mdwn +++ b/openpower/sv/svp_rewrite/svp64.mdwn @@ -347,9 +347,10 @@ TODO, important, particularly for crops, mfcr and mtcr, what elwidth even means. instead it may be possible to use the bits as extra indices (EXTRA6) to access the full 64 CRs. TBD, several ideas -The actual width of the CRs cannot be altered: they are 4 bit. Thus, -for Rc=1 operations that produce a result and corresponding CR, it is -the result to which the elwidth override applies, not the CR. +The actual width of the CRs cannot be altered: they are 4 bit. Also, +for Rc=1 operations that produce a result (in RT or FRT) and corresponding CR, it is +the INT/FP result to which the elwidth override applies, *not* the CR. +This therefore inherently places Rc=1 operations firmly out of scope as far as a "meaning" for elwidth on CRs is concerned. As mentioned TBD, this leaves crops etc. to have a meaning defined for elwidth, because these ops are pure explicit CR based.