From eff8928eff56b8f4d8dd4cd0c945cb5f42ea4527 Mon Sep 17 00:00:00 2001 From: lkcl Date: Wed, 14 Sep 2022 18:52:48 +0100 Subject: [PATCH] --- openpower/sv/rfc/ls001.mdwn | 35 +++++++++++++++++++++++++++++++---- 1 file changed, 31 insertions(+), 4 deletions(-) diff --git a/openpower/sv/rfc/ls001.mdwn b/openpower/sv/rfc/ls001.mdwn index 67c87bd4a..8bc64c28f 100644 --- a/openpower/sv/rfc/ls001.mdwn +++ b/openpower/sv/rfc/ls001.mdwn @@ -279,6 +279,10 @@ These options provide the ability to cover the majority of Parallel 3D GPU Conditions, saving a not inconsiderable number of instructions especially given the close interaction with CTR in hot-loops. +Also `SVLR` is introduced, which is a parallel twin of `LR`, and saving +and restoring of LR and SVLR may be deferred until the final decision +as to whether to branch. In this way `sv.bclrl` does not corrupt `LR`. + **SVP64Single** The `SVP64-Single` 24-bit encoding focusses primarily on ensuring that @@ -294,11 +298,14 @@ all 64-bit encodings. This is a Computer Science term that needed first to be invented. There exists only one other Vertical-First Vector ISA in the world: -Mitch Alsup's VVM Extension for the 66000. +Mitch Alsup's VVM Extension for the 66000. Several people have +independently derived Vertical-First: it simply did not have a +Computer Science term associated with it. If we envisage register and Memory layout to be Horizontal and -instructions to be vertical, and to then have some form of Loop -System it is easier to conceptualise VF vs HF Mode: +instructions to be Vertical, and to then have some form of Loop +System (wherther Zero-Overhead or just branch-conditional based) +it is easier to then conceptualise VF vs HF Mode: * Vertical-First progresses through *instructions* first before moving on to the next *register* (or Memory-address in the case @@ -307,7 +314,27 @@ System it is easier to conceptualise VF vs HF Mode: through **registers** (or, register *elements* in traditional Cray-Vector ISAs) in full before moving on to the next instruction. - +Mitch Alsup's VVM Extension is a form of hardware-level auto-vectorisation +based around Zero-Overhead Loops. Using a Variable-Length Encoding all +loop-invariant registers are "tagged" such that the Hazard Management +Engine may perform optimally and do less work in automatically identifying +parallelism opportunities. +With it not being appropriate to use Variable-Length Encoding in the Power +ISA a different much more explicit strategy was taken in Simple-V. + +The biggest advantage inherent in Vertical-First is that it is very easy +to introduce into compilers, because all looping, as far as the architecture +is concerned, remains expressed as *Scalar assembler*. Whilst Mitch Alsup's +VVM advocates auto-vectorisation and is limited in its ability to call +functions, Simple-V's Vertical-First provides explicit control over the +parallelism ("hphint") and also allows for full state to be stored/restored +(SVLR combined with LR), permitting full function calls to be made. + +Simple-V Vertical-First Looping requires an explicit instruction to +move `SVSTATE` regfile offsets forward: `svstep`. An early version of +Vectorised +Branch-Conditional attempted to merge the functionality of `svstep` +into `sv.bc`: it became CISC-like and was reverted. \newpage{} # Simple-V REMAP subsystem -- 2.30.2