From 354cd93ede151b36546e62caf2dbfa4b778b9bb6 Mon Sep 17 00:00:00 2001 From: lkcl Date: Mon, 11 Oct 2021 17:13:16 +0100 Subject: [PATCH] --- openpower/sv/svp64.mdwn | 17 +++-------------- 1 file changed, 3 insertions(+), 14 deletions(-) diff --git a/openpower/sv/svp64.mdwn b/openpower/sv/svp64.mdwn index 28995f116..9a1dbe94d 100644 --- a/openpower/sv/svp64.mdwn +++ b/openpower/sv/svp64.mdwn @@ -256,21 +256,10 @@ v3.0B "single" FP. ## Elwidth for CRs: -TODO, important, particularly for crops, mfcr and mtcr, what elwidth -even means. instead it may be possible to use the bits as extra indices -(add to EXTRA2/3) to access the full 128 CRs at the bit level. TBD, several ideas +Element-width overrides for CR Fields has no meaning. The bits +are therefore used for other purposes, or when Rc=1, the Elwidth +applies to the result being tested, but not to the Vector of CR Fields. -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. - -Examples: mfxm may take the extra bits and use them as extra mask bits. - -Example: hypothetically, operations could be modified to be considered 2-bit or 1-bit per CR. This would need a very comprehensive review. # SUBVL Encoding -- 2.30.2