From 6682c9229e35f301d2ad4839c82f6cd063400928 Mon Sep 17 00:00:00 2001 From: lkcl Date: Tue, 22 Dec 2020 03:36:53 +0000 Subject: [PATCH] --- openpower/sv/svp_rewrite/svp64.mdwn | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/openpower/sv/svp_rewrite/svp64.mdwn b/openpower/sv/svp_rewrite/svp64.mdwn index 255b9f306..54a764484 100644 --- a/openpower/sv/svp_rewrite/svp64.mdwn +++ b/openpower/sv/svp_rewrite/svp64.mdwn @@ -42,8 +42,6 @@ v3.0/1B instructions covered by the prefix are "unaltered". This is termed `scal Note that this is completely different from when VL=0. VL=0 turns all operations under its influence into `nops` (regardless of the prefix) whereas when VL=1 and the SV prefix is all zeros, the operation simply acts as if SV had not been applied at all to the instruction (an "identity operation"). - - # Register Naming and size SV Registers are simply the INT, FP and CR register files extended @@ -100,10 +98,13 @@ empty spaces are yet-to-be-allocated Illegal Instructions. |110---| MRR | | | | `SVP64`| `SVP64`| `SVP64`| `SVP64`| |111---| | MMIRR | | | `SVP64`| `SVP64`| `SVP64`| `SVP64`| +Note that by taking up a block of 16, where in every case bits 6 and 9 are set, this allows svp64 to utilise four bits of the v3.1B Prefix space and "allocate" them to svp64's Remapped Encoding field, instead. + ## Prefix Fields To "activate" svp64, fields within the v3.1B Prefix Opcode Map are set (see Prefix Opcode Map, above), leaving 24 bits "free" for use by SV. +This is achieved by setting bits 7 and 9 to 1: | Name | Bits | Value | Description | |------------|---------|-------|--------------------------------| @@ -123,7 +124,7 @@ are constructed: | 000001 | RM[0] | 1 | RM[1] | 1 | RM]2:23] | Following the prefix will be the suffix: this is simply a 32-bit v3.0B / v3.1B -instruction. That instruction is "prefixed" with the SV context: the +instruction. That instruction becomes "prefixed" with the SVP context: the Remapped Encoding field (RM). # Remapped Encoding Fields -- 2.30.2