From: lkcl Date: Sat, 2 Apr 2022 00:00:08 +0000 (+0100) Subject: (no commit message) X-Git-Tag: opf_rfc_ls005_v1~2943 X-Git-Url: https://git.libre-soc.org/?a=commitdiff_plain;h=f7f5987ae365b44c7ea598b3bc40bc24ac7c85d9;p=libreriscv.git --- diff --git a/openpower/sv/cr_ops.mdwn b/openpower/sv/cr_ops.mdwn index c66611743..375ff81b4 100644 --- a/openpower/sv/cr_ops.mdwn +++ b/openpower/sv/cr_ops.mdwn @@ -16,7 +16,8 @@ width (which is clearly meaningless for a 4-bit collation of Conditions, EQ LT GE SO). Likewise, arithmetic saturation (an important part of Arithmetic SVP64) has no meaning. Additionally, extra modes are required that only make -sense for Vectorised CR Operations. Consequently an alternative Mode Format is required. +sense for Vectorised CR Operations. Consequently an alternative Mode Format is required, and given that elwidths are meaningless for CR Fields +the bits in SVP64 `RM` may be used for other purposes. This alternative mapping **only** applies to instructions that **only** reference a CR Field or CR bit as the sole exclusive result. This section @@ -66,6 +67,16 @@ predicates may themselves be Condition Registers it can be seen that there could potentially be up to **six** CR Fields involved in the execution of Predicate-result Mode. +A reminder that, just as with other SVP64 Modes, unlike v3.1 64 bit +Prefixing there are insufficient bits spare in the prefix to mark +the type. Therefore, the SVP64 Mode must be identified by first +decoding the suffix (the 32 bit scalar operation), and, once +the instruction is identified (cmpi, mfcr, crweird) +only then may the type of SVP64 Mode (normal, branch, LDST, CR 3-bit +or CR 5-bit) be decoded. + +# Format + SVP64 RM `MODE` (includes `ELWIDTH` bits) for CR-based operations: | 4 | 5 | 19-20 | 21 | 22 23 | description |