From: lkcl Date: Sun, 3 Apr 2022 19:48:34 +0000 (+0100) Subject: (no commit message) X-Git-Tag: opf_rfc_ls005_v1~2890 X-Git-Url: https://git.libre-soc.org/?a=commitdiff_plain;h=be80483997196e8dbcdd36a3442e0262bf7ff7b0;hp=868fa6845104382edc398d9fcc11fc46b60a9bcc;p=libreriscv.git --- diff --git a/openpower/sv/cr_ops.mdwn b/openpower/sv/cr_ops.mdwn index 2fc35197f..7b09514ae 100644 --- a/openpower/sv/cr_ops.mdwn +++ b/openpower/sv/cr_ops.mdwn @@ -53,20 +53,12 @@ Other modes are still applicable and include: for analysing a Vector of Condition Register Fields and reducing it to one single Condition Register Field. -* **Predicate-result**. - An augmentation to predication in that only elements which pass a test -on the result carried out *by the instruction itself* -will end up actually being modified. This is in effect the same -as ANDing the Condition Test with the destination predicate -mask (hence the name, "predicate-result"). - -Predicate-result is a particularly powerful strategic mode -in that it is the interaction of a source predicate, destination predicate, -input operands *and* the output result, all combining to influence -what actually goes into the Condition Register File. Given that -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. + +Predicate-result unfortunately does not make any sense because +when Rc=1 a co-result is created (a CR Field). Testing the co-result +allows the decision to be made to store or not store the main +result, and unfortunately for CR Ops the CR Field result *is* +the main result. 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 @@ -88,8 +80,7 @@ SVP64 RM `MODE` (includes `ELWIDTH` bits) for CR-based operations: |sz |SNZ| 00 | 1 | SVM RG | subvector reduce mode, SUBVL>1 | |sz |SNZ| 01/10 | inv | CR-bit | Ffirst 3-bit mode | |sz |SNZ| 01/10 | inv | dz / | Ffirst 5-bit mode | -|sz |SNZ| 11 | inv | CR-bit | 3-bit pred-result CR sel | -|sz |SNZ| 11 | inv | dz / | 5-bit pred-result z/nonz | +|sz |SNZ| 11 | rsv | rsvd | reserved | `VLI=0` when bits 19-20=0b01. `VLI=1` when bits 19-20=0b10. @@ -201,48 +192,3 @@ elements thereafter: for i in VL-1 downto 0 # reverse gear CR[4+i].ge &= CR[5+i].ge - - -# Predicate-result Condition Register operations - -These are again slightly different compared to SVP64 arithmetic -pred-result (described in [[svp64/appendix]]). The reason is that, -again, for arithmetic operations the production of a CR Field when -Rc=1 is a *co-result* accompanying the main arithmetic result, whereas -for CR-based operations the CR Field (referred to by a 3-bit -v3.0B base operand from e.g. `mfcr`) or CR bit (referred to by a 5-bit operand from e.g. `crnor`) -*is* itself the explicit and sole result of the operation. - -Therefore, logically, Predicate-result needs to be adapted to -test the actual result of the CR-based instruction (rather than -test the co-resultant CR when Rc=1, as is done for Arithmetic SVP64). - - for i in range(VL): - # predication test, skip all masked out elements. - # skips when sz=0 - if sz=0 and predicate_masked_out(i): - continue - if predicate_masked_out(i): - if 5bit mode: - # only one bit of CR to update - result = SNZ - else - # four copies of SNZ - result = SNZ || SNZ || SNZ || SNZ - else - # result is to go into CR. may be a 4-bit CR Field - # (3-bit mode) or just a single bit (5-bit mode) - result = op(...) - if 5bit mode: - # if this CR op has 5-bit CR result operands - # the single bit result is what must be tested - to_test = result - else - # if however this is a 3-bit CR *field* result - # then the bit to be tested must be selected - to_test = result[CRbit] - # now test CR, similar to branch - if to_test != inv: - continue # test failed: cancel store - # result optionally stored - update_CR(result)