From 00baf14d8a492c8997fbb68bd66da2f09858fc6b Mon Sep 17 00:00:00 2001 From: Luke Kenneth Casson Leighton Date: Sun, 24 Jul 2022 01:15:30 +0100 Subject: [PATCH] rename OpenPOWER back to Power, should not have been changed --- openpower/sv/sprs.mdwn | 2 +- openpower/sv/svp64.mdwn | 24 ++++++++++++------------ 2 files changed, 13 insertions(+), 13 deletions(-) diff --git a/openpower/sv/sprs.mdwn b/openpower/sv/sprs.mdwn index 43af74f4d..5bda4fa41 100644 --- a/openpower/sv/sprs.mdwn +++ b/openpower/sv/sprs.mdwn @@ -2,7 +2,7 @@ # SPRs -Note OpenPOWER v3.1 p12: +Note Power ISA v3.1 p12: The designated SPR sandbox consists of non-privileged SPRs 704-719 and privileged SPRs 720-735. diff --git a/openpower/sv/svp64.mdwn b/openpower/sv/svp64.mdwn index 83acd9202..5a8b215d3 100644 --- a/openpower/sv/svp64.mdwn +++ b/openpower/sv/svp64.mdwn @@ -1,10 +1,10 @@ [[!tag standards]] -# DRAFT SVP64 for OpenPOWER ISA v3.0B +# DRAFT SVP64 for Power ISA v3.0B * **DRAFT STATUS v0.1 18sep2021** Release notes -This document describes [[SV|sv]] augmentation of the [[OpenPOWER|openpower]] v3.0B [[ISA|openpower/isa/]]. It is in Draft Status and +This document describes [[SV|sv]] augmentation of the [[Power|openpower]] v3.0B [[ISA|openpower/isa/]]. It is in Draft Status and will be submitted to the [[!wikipedia OpenPOWER_Foundation]] ISA WG via the External RFC Process. @@ -81,14 +81,14 @@ supported in hardware must also raise illegal instruction traps in order to allow emulation. Unless otherwise stated, reserved values are always all zeros. -This is unlike OpenPower ISA v3.1, which in many instances does not require a trap if reserved fields are nonzero. Where the standard OpenPOWER definition +This is unlike OpenPower ISA v3.1, which in many instances does not require a trap if reserved fields are nonzero. Where the standard Power ISA definition is intended the red keyword `RESERVED` is used. # Scalar Identity Behaviour SVP64 is designed so that when the prefix is all zeros, and VL=1, no effect or -influence occurs (no augmentation) such that all standard OpenPOWER +influence occurs (no augmentation) such that all standard Power ISA v3.0/v3 1 instructions covered by the prefix are "unaltered". This is termed `scalar identity behaviour` (based on the mathematical definition for "identity", as in, "identity matrix" or better "identity transformation"). Note that this is completely different from when VL=0. VL=0 turns all operations under its influence into `nops` (regardless of the prefix) @@ -100,13 +100,13 @@ SV Registers are simply the INT, FP and CR register files extended linearly to larger sizes; SV Vectorisation iterates sequentially through these registers. Where the integer regfile in standard scalar -OpenPOWER v3.0B/v3.1B is r0 to r31, SV extends this as r0 to r127. +Power ISA v3.0B/v3.1B is r0 to r31, SV extends this as r0 to r127. Likewise FP registers are extended to 128 (fp0 to fp127), and CR Fields are extended to 128 entries, CR0 thru CR127. The names of the registers therefore reflects a simple linear extension -of the OpenPOWER v3.0B / v3.1B register naming, and in hardware this +of the Power ISA v3.0B / v3.1B register naming, and in hardware this would be reflected by a linear increase in the size of the underlying SRAM used for the regfiles. @@ -134,7 +134,7 @@ is defined in the Prefix Fields section. ## Prefix Opcode Map (64-bit instruction encoding) -In the original table in the v3.1B OpenPOWER ISA Spec on p1350, Table 12, prefix bits 6:11 are shown, with their allocations to different v3.1B pregix "modes". +In the original table in the v3.1B Power ISA Spec on p1350, Table 12, prefix bits 6:11 are shown, with their allocations to different v3.1B pregix "modes". The table below hows both PowerISA v3.1 instructions as well as new SVP instructions fit; empty spaces are yet-to-be-allocated Illegal Instructions. @@ -215,7 +215,7 @@ on context after decoding of the Scalar suffix: * MASK (and MASK_SRC) and MASKMODE provide predication (two types of sources: scalar INT and Vector CR). * Bits 10 to 18 (EXTRA) are further decoded depending on the RM category for the instruction, which is determined only by decoding the Scalar 32 bit suffix. -Similar to OpenPOWER `X-Form` etc. EXTRA bits are given designations, such as `RM-1P-3S1D` which indicates for this example that the operation is to be single-predicated and that there are 3 source operand EXTRA tags and one destination operand tag. +Similar to Power ISA `X-Form` etc. EXTRA bits are given designations, such as `RM-1P-3S1D` which indicates for this example that the operation is to be single-predicated and that there are 3 source operand EXTRA tags and one destination operand tag. Note that if ELWIDTH != ELWIDTH_SRC this may result in reduced performance or increased latency in some implementations due to lane-crossing. @@ -337,7 +337,7 @@ this creates an unnecessary block on parallelism. Therefore, it is up to the programmer to ensure that the CR fields used as Predicate Masks are not being written to by any parallel Vector Loop. Doing so results in **UNDEFINED** behaviour, according to the definition -outlined in the OpenPOWER v3.0B Specification. +outlined in the Power ISA v3.0B Specification. Hardware Implementations are therefore free and clear to delay reading of individual CR fields until the actual predicated element operation @@ -400,7 +400,7 @@ Masks have to be adapted to fit on these boundaries as well. # Extra Remapped Encoding -Shows all instruction-specific fields in the Remapped Encoding `RM[10:18]` for all instruction variants. Note that due to the very tight space, the encoding mode is *not* included in the prefix itself. The mode is "applied", similar to OpenPOWER "Forms" (X-Form, D-Form) on a per-instruction basis, and, like "Forms" are given a designation (below) of the form `RM-nP-nSnD`. The full list of which instructions use which remaps is here [[opcode_regs_deduped]]. (*Machine-readable CSV files have been provided which will make the task of creating SV-aware ISA decoders easier*). +Shows all instruction-specific fields in the Remapped Encoding `RM[10:18]` for all instruction variants. Note that due to the very tight space, the encoding mode is *not* included in the prefix itself. The mode is "applied", similar to Power ISA "Forms" (X-Form, D-Form) on a per-instruction basis, and, like "Forms" are given a designation (below) of the form `RM-nP-nSnD`. The full list of which instructions use which remaps is here [[opcode_regs_deduped]]. (*Machine-readable CSV files have been provided which will make the task of creating SV-aware ISA decoders easier*). These mappings are part of the SVP64 Specification in exactly the same way as X-Form, D-Form. New Scalar instructions added to the Power ISA @@ -561,7 +561,7 @@ is limited. ## INT/FP EXTRA3 If EXTRA3 is zero, maps to -"scalar identity" (scalar OpenPOWER ISA field naming). +"scalar identity" (scalar Power ISA field naming). Fields are as follows: @@ -588,7 +588,7 @@ Fields are as follows: ## INT/FP EXTRA2 If EXTRA2 is zero will map to -"scalar identity behaviour" i.e Scalar OpenPOWER register naming: +"scalar identity behaviour" i.e Scalar Power ISA register naming: | Value | Mode | Range/inc | 6..0 | |-----------|-------|---------------|-----------| -- 2.30.2