From 589d2181a6e1dbadf4b5ab70c3acecb275f55cb7 Mon Sep 17 00:00:00 2001 From: Luke Kenneth Casson Leighton Date: Sun, 11 Sep 2022 17:00:06 +0100 Subject: [PATCH] add new encoding table section --- openpower/sv/rfc/ls001.mdwn | 84 +++++++++++++++++++++++++++++++++++++ 1 file changed, 84 insertions(+) diff --git a/openpower/sv/rfc/ls001.mdwn b/openpower/sv/rfc/ls001.mdwn index 4495d068d..d8adeb3a6 100644 --- a/openpower/sv/rfc/ls001.mdwn +++ b/openpower/sv/rfc/ls001.mdwn @@ -393,6 +393,90 @@ The issues of allocation for bitmanip etc. from Libre-SOC is therefore overwhelmingly made moot. The only downside is that there is no `SVP64-Reserved` which will have to be achieved with SPRs (PCR or MSR). +\newpage{} +**EXT000-EXT031** + +These are Scalar word-encodings. Often termed "v3.0 Scalar" in this document +Power ISA v3.1 Section 1.6.3 Book I calls it a "Scalar word". + +| 0-5 | 6-31 | +|--------|--------| +| PO | EXT000-031 Scalar (v3.0 or v3.1) operation | + +**RESERVED2 / EXT300-363** + +This is entirely at the discretion of the ISA WG. Libre-SOC is *not* +proposing the addition of EXT300-363: it is merely a possibility for +future. The reason the space is not needed is because this is within +the realm of Scalar-extended (SVP64Single), and with the 24-bit prefix +area being all-zero (bits 8-31) this is defined as "having no augmentation" +(in the Simple-V Specification it is termed `Scalar Identity Behaviour`). +This in turn makes this prefix *entirely redundant* so may be allocated +for other purposes. + +| 0-5 | 6 | 7 | 8-31 | 32-63 | +|--------|---|---|-------|---------| +| PO (9)?| 1 | 0 | 0000 | EXT300-363 or `RESERVED1` | + +**{EXT200-263}** + +This encoding represents the opportunity to introduce EXT200-263. +It is a Scalar-word encoding, and does not require implementing +SVP64 or SVP64-Single. +PO2 is in the range 0b00000 to 0b11111 to represent EXT200-263 respectively. + +| 0-5 | 6 | 7 | 8-31 | 32-37 | 38-63 | +|--------|---|---|-------|--------|---------| +| PO (9)?| 0 | 0 | 0000 | PO2 | {EXT200-263} | + +**SVP64Single:{EXT200-263}** + +This encoding, which is effectively VL=1 and comprising (from bits 8-31) +*at least some* form of Augmentation, it represents the opportunity +to Augment EXT200-263 with the SVP64Single capabilities. +Instructions may not be placed in this category without also being +implemented as pure Scalar. + +| 0-5 | 6 | 7 | 8-31 | 32-37 | 38-63 | +|--------|---|---|-------|--------|---------| +| PO (9)?| 0 | 0 | !zero | PO2 | SVP64Single:{EXT200-263} | + +**SVP64Single:{EXT000-063}** + +This encoding, identical to SVP64Single:{EXT200-263}, +introduces SVP64Single Augmentation of v3.0 Scalar word instructions. +All meanings must be identical to EXT000 to EXT063, and is is likewise +prohibited to add an instruction in this area without also adding +the exact same (non-Augmented) instruction in EXT000-063 with the +exact same Scalar word. +PO2 is in the range 0b00000 to 0b11111 to represent EXT000-063 respectively. +Augmenting EXT001 is prohibited. + +**SVP64:{EXT200-263}** + +This encoding, which permits VL to be dynamic (settable from GPR or CTR) +is the Vectorisation of EXT200-263. +Instructions may not be placed in this category without also being +implemented as pure Scalar *and* SVP64Single. Unlike SVP64Single +however, there is **no reserved encoding** (bits 8-24 zero). +VL=1 may occur dynamically +at runtime, even when bits 8-31 are zero. + +| 0-5 | 6 | 7 | 8-31 | 32-37 | 38-63 | +|--------|---|---|-------|--------|---------| +| PO (9)?| 0 | 1 | nnnn | PO2 | SVP64:{EXT200-263} | + +**SVP64:{EXT000-063}** + +This encoding is identical to **SVP64:{EXT200-263}** except it +is the Vectorisation of existing v3.0/3.1 Scalar-words, EXT000-063. +All the same rules apply with the addition that +Vectorisation of EXT001 is prohibited. + +| 0-5 | 6 | 7 | 8-31 | 32-37 | 38-63 | +|--------|---|---|-------|--------|---------| +| PO (9)?| 1 | 1 | nnnn | PO2 | SVP64:{EXT000-063} | + \newpage{} # Use cases -- 2.30.2