From aa15dda5f86872bd5f5ba79d0f130b34b8969236 Mon Sep 17 00:00:00 2001 From: lkcl Date: Thu, 2 Jun 2022 21:37:18 +0100 Subject: [PATCH] --- openpower/sv/svp64_quirks.mdwn | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) diff --git a/openpower/sv/svp64_quirks.mdwn b/openpower/sv/svp64_quirks.mdwn index f95cb992c..eeea9655d 100644 --- a/openpower/sv/svp64_quirks.mdwn +++ b/openpower/sv/svp64_quirks.mdwn @@ -111,6 +111,23 @@ All of these differences, which require quite a lot of logical reasoning and deduction, help explain why there is an entirely different CR ops Vectorisation Category. +A particularly strange quirk of CR-based Vector Operations is that the +Scalar Power ISA CR Register is 32-bits, but actually comprises eight +CR Fields, CR0-CR7. With each CR Field being four bits (EQ, LT, GT, SO) +this makes up 32 bits, and therefore a CR operand referring to one bit +of the CR will be 5 bits in length. *However*, some instructions refer +to a *CR Field* (CR0-CR7) and consequently are only 3-bits. + +With SVP64 extending the number of CR *Fields* to 128, the number of +CR *Registers* extends to 16, in order to hold all 128 CR *Fields* +(8 per CR Register). Then, it gets even more strange, when it comes +to Vectorisation, which applies to the CR *Field* numbers. The +hardware-for-loop for Rc=1 for example starts at CR0 for element 0, +and moves to CR1 for element 1, and so on. In other words, the +element is the 4-bit CR *Field*, not the bits *of* the 32-bit +CR Register, and not the CR *Register* (of which there are now 16). +All quite logical, but a little mind-bending. + **Load/Store** LOAD/STORE is another area that has different needs: this time it is -- 2.30.2