(no commit message)
authorlkcl <lkcl@web>
Wed, 14 Sep 2022 20:46:11 +0000 (21:46 +0100)
committerIkiWiki <ikiwiki.info>
Wed, 14 Sep 2022 20:46:11 +0000 (21:46 +0100)
openpower/sv/rfc/ls001.mdwn

index 431bc4306fb622376d3638f02b987c768818e7cd..08f6743f95eaaf8f3c8d929a01ffd1053559356a 100644 (file)
@@ -292,10 +292,12 @@ or desirable.
 
 Some considerable care has been taken to ensure that Decoding may be
 performed in a strict forward-pipelined fashion that, aside from changes in
-SVSTATE and aside from the initial 32/64 length detection (also kept simple),
+SVSTATE (necessarily cached and propagated alongside MSR and PC)
+and aside from the initial 32/64 length detection (also kept simple),
 a Multi-Issue Engine would have no difficulty (performance maximisable).
-With the initial partial RM identification
-decode performed above the Vector operations may easily be passed downstream
+With the initial partial RM Mode type-identification
+decode performed above the Vector operations may then
+easily be passed downstream in a fully forward-progressive piplined fashion
 to independent parallel units for further analysis.
 
 **Vectorised Branch-Conditional**
@@ -325,7 +327,7 @@ 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**
+# SVP64Single 24-bits
 
 The `SVP64-Single` 24-bit encoding focusses primarily on ensuring that
 all 128 Scalar registers are fully accessible, provides element-width
@@ -336,11 +338,18 @@ provided in the Scalar Power ISA without one single explicit FP16 or BF16
 32-bit opcode being added.  The downside: such Scalar operations are
 all 64-bit encodings.
 
+As SVP64Single is new and still under development, space for it may
+instead be `RESERVED`. It is however necessary as there are limitations
+in SVP64 Register numbering, particularly for 4-operand instructions,
+that can only be easily overcome by SVP64Single.
+
 # Vertical-First Mode
 
 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. Several people have
+Mitch Alsup's VVM Extension for the 66000, details of which may be
+obtained publicly on `comp.arch` or directly from Mitch Alsup under
+NDA. Several people have
 independently derived Vertical-First: it simply did not have a
 Computer Science term associated with it.
 
@@ -354,7 +363,7 @@ it is easier to then conceptualise VF vs HF Mode:
   of Mitch Alsup's VVM).
 * Horizontal-First (also known as Cray-style Vectors) progresses
   through **registers** (or, register *elements* in traditional
-  Cray-Vector ISAs) in full before moving on to the next instruction.
+  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