From: lkcl Date: Fri, 27 May 2022 08:58:34 +0000 (+0100) Subject: (no commit message) X-Git-Tag: opf_rfc_ls005_v1~2069 X-Git-Url: https://git.libre-soc.org/?a=commitdiff_plain;h=5122c4c443b07ca1ca1289b80c61034a2deb60de;p=libreriscv.git --- 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)