From c1297a022ac234442cda41918347ae27108d3b95 Mon Sep 17 00:00:00 2001 From: lkcl Date: Mon, 2 May 2022 06:16:22 +0100 Subject: [PATCH] --- openpower/sv/svp64.mdwn | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/openpower/sv/svp64.mdwn b/openpower/sv/svp64.mdwn index 567aa1656..1d576b902 100644 --- a/openpower/sv/svp64.mdwn +++ b/openpower/sv/svp64.mdwn @@ -74,7 +74,8 @@ This document focusses specifically on how that fits into available space. The For the new fields added in SVP64, instructions that have any of their fields set to a reserved value must cause an illegal instruction trap, -to allow emulation of future instruction sets. Unless otherwise stated, reserved values are always all zeros. +to allow emulation of future instruction sets. This includes SVP64 SPRs. +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 is intended the red keyword `RESERVED` is used. @@ -91,6 +92,11 @@ Note that this is completely different from when VL=0. VL=0 turns all operation The significance of identity behaviour is that instructions added under svp64 to the 32 bit suffix are not only accessible to svp64: as long as implementors conform to identity behaviour (set the prefix to all zeros) they may use the instructions without needing to actually implement SV itself. +Implementors intending only to implement Scalar operations (identity behaviour only) +are however required to at least support the SVSTATE +SPR, which if nonzero (no longer identity behaviour) must cause all SVP64 instructions to raise an illegal instruction trap. This allows full +soft-implementation of SVP64. + # Register Naming and size SV Registers are simply the INT, FP and CR register files extended -- 2.30.2