From dd265c071914bc8c7648a80782f8202d4d557325 Mon Sep 17 00:00:00 2001 From: lkcl Date: Mon, 29 May 2023 16:15:38 +0100 Subject: [PATCH] --- openpower/sv/svp64.mdwn | 40 +++++++++++++++++++++++----------------- 1 file changed, 23 insertions(+), 17 deletions(-) diff --git a/openpower/sv/svp64.mdwn b/openpower/sv/svp64.mdwn index 1942922f8..2a9c6f2c0 100644 --- a/openpower/sv/svp64.mdwn +++ b/openpower/sv/svp64.mdwn @@ -191,15 +191,24 @@ without also adding hardware support for SVP64-Prefixing of the same.* should be considered Unvectorizable and except in extreme mitigating circumstances rejected outright.* -## Definition of Strict Program Order +## Definition of Strict Element-Level Execution Order -Strict Program Order is defined as giving the appearance, as far +Where Instruction Execution Order[^ieo] guarantees the appearance of sequential +execution of instructions, Simple-V requires a corresponding guarantee for Elements +because in Simple-V Execution of Elements is synonymous with Execution of +instructions. + +## Precise Interrupt Guarantees + +Strict Instruction Execution Order[^ieo] is defined as giving the appearance, as far as programs are concerned, that instructions were executed strictly in the sequence that they occurred. A "Precise" out-of-order Micro-architecture goes to considerable lengths to ensure that this is the case. +[^ieo]: Strict Instruction Execution Order is defined in Public v3.1 Book I Section 2.2 + Many Vector ISAs allow interrupts to occur in the middle of processing of large Vector operations, only under the condition that partial results are cleanly discarded, and continuation on return @@ -211,27 +220,24 @@ that specifies a higher degree of accuracy for the *internal* accumulator than the registers. Simple-V operates on an entirely different paradigm from traditional -Vector ISAs: as a Sub-Program Counter where "Elements" are synonymous +Vector ISAs: as a "Sub-Execution Context", where "Elements" are synonymous with Scalar instructions. With this in mind it is critical for -implementations to observe Strict Element-Level Program Order -at all times -(often simply referred to as just "Strict Program Order" -throughout -this Chapter). -*Any* element is Interruptible and Simple-V has -been carefully designed to guarantee that Architectural State may -be fully preserved and restored regardless of that same State, but -it is not necessarily guaranteed that the amount of time needed to recover -will be low latency (particularly if REMAP -is active). +implementations to observe Strict **Element**-Level Execution Order[^svp64_eeo] +at all times. +*Any* element is Interruptible and Architectural State may +be fully preserved and restored regardless of that same State + +*Engineering note: implementations are permitted have higher latency to +perform context-switching (particularly if REMAP +is active).* Interrupts still only save `MSR` and `PC` in `SRR0` and `SRR1` but the full SVP64 Architectural State may be saved and restored through manual copying of `SVSTATE` (and the four REMAP SPRs if in use at the time) -Whilst this initially sounds unsafe in reality -all that Trap Handlers (and function call stack save/restore) -need do is avoid + +*Programmer's note: Trap Handlers (and function call stack save/restore) +may avoid the use of SVP64 Prefixed instructions to perform the necessary save/restore of Simple-V Architectural State. This capability also allows nested function calls to be made from -- 2.30.2