From 5122c4c443b07ca1ca1289b80c61034a2deb60de Mon Sep 17 00:00:00 2001 From: lkcl Date: Fri, 27 May 2022 09:58:34 +0100 Subject: [PATCH] --- openpower/sv/svp64_quirks.mdwn | 18 +++++++++++++++++- 1 file changed, 17 insertions(+), 1 deletion(-) diff --git a/openpower/sv/svp64_quirks.mdwn b/openpower/sv/svp64_quirks.mdwn index 6d1b0e51e..754b510da 100644 --- a/openpower/sv/svp64_quirks.mdwn +++ b/openpower/sv/svp64_quirks.mdwn @@ -8,6 +8,22 @@ SVP64 is designed around these fundamental and inviolate principles: with scalar instructions (the suffix) That said, there are a few exceptional places where these rules get -bent, and this page tracks them. +bent, and others where the rules take some explaining, +and this page tracks them. # CR weird instructions + +[[sv/int_cr_predication]] is by far the biggest violator of the SVP64 +rules, for good reasons. Transfers between Vectors of CR Fields and Integers +for use as predicates is very awkward without them. + +Normally, element width overrides allow the element width to be specified +as 8, 16, 32 or default (64) bit. With CR weird instructions producing or +consuming either 1 bit or 4 bit elements (in effect) some adaptation was +required. When this perspective is taken (that results or sources are +1 or 4 bits) the weirdness starts to make sense, because the "elements", +such as they are, are still packed sequentially. + +From a hardware implementation perspective however they will need special +handling as far as Hazard Dependencies are concerned, due to nonconformance +(bit-level management) -- 2.30.2