From 17240c0c10d43b9ba3553fd85ab6895f9f4f4b92 Mon Sep 17 00:00:00 2001 From: lkcl Date: Thu, 19 May 2022 18:18:15 +0100 Subject: [PATCH] --- openpower/sv/cr_int_predication.mdwn | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/openpower/sv/cr_int_predication.mdwn b/openpower/sv/cr_int_predication.mdwn index 6c5d7cb93..d66dfc507 100644 --- a/openpower/sv/cr_int_predication.mdwn +++ b/openpower/sv/cr_int_predication.mdwn @@ -362,7 +362,11 @@ occurs: of which are packed into the first 16-bit destination element, the second four of which are packed into the second 16-bit destination element. -Pseudocode example (dest elwidth overrides not included): +Pseudocode example: note that dest elwidth overrides affect the +packing of results. BB.elwidth in effect requests how many 4-bit +result elements would like to be packed, but RT.elwidth determines +the limit. Any parts of the destination elements not containing +results are set to zero. for i in range(VL): if BB.isvec: @@ -375,7 +379,9 @@ Pseudocode example (dest elwidth overrides not included): n3 = mask[3] & (mode[3] == creg[3]) result = n0||n1||n2||n3 # 4-bit result if RT.isvec: - # TODO: RT.elwidth override to be also added here + # RT.elwidth override can affect the packing + bwid = {0b00:64, 0b01:8, 0b10:16, 0b11:32}[RT.elwidth] + t4, t8 = min(4, bwid//2), min(8, bwid//2) # yes, really, the CR's elwidth field determines # the bit-packing into the INT! if BB.elwidth == 0b00: -- 2.30.2