(no commit message)

[libreriscv.git] / openpower / sv / SimpleV_rationale.mdwn

diff --git a/openpower/sv/SimpleV_rationale.mdwn b/openpower/sv/SimpleV_rationale.mdwn
index ff0bb23f4d79cdfbe61656e4f542ab06194d6f37..89ead34078ca1ce6460db4f0865422cf94cba489 100644 (file)
--- a/openpower/sv/SimpleV_rationale.mdwn
+++ b/openpower/sv/SimpleV_rationale.mdwn
@@ -2,11 +2,12 @@
 
 **Revision History**
 
-* v0.00 05may2021 first created
-* v0.01 06may2021 initial first draft
-* v0.02 08may2021 add scenarios / use-cases
-* v0.03 09may2021 add draft image for scenario
-* v0.04 14may2021 add appendix with other research
+* v0.00 05may2022 first created
+* v0.01 06may2022 initial first draft
+* v0.02 08may2022 add scenarios / use-cases
+* v0.03 09may2022 add draft image for scenario
+* v0.04 14may2022 add appendix with other research
+* v0.05 14jun2022 update images (thanks to Veera)
 
 **Table of Contents**
 
@@ -276,7 +277,9 @@ Vector instructions in RISC-V as there are in the RV64GC Scalar base.
 The question then becomes: with all the duplication of arithmetic
 operations just to make the registers scalar or vector, why not
 leverage the *existing* Scalar ISA with some sort of "context"
-or prefix that augments its behaviour? Make "Scalar instruction"
+or prefix that augments its behaviour? Separate out the
+"looping" from "thing being looped on" (the elements),
+make "Scalar instruction"
 synonymous with "Vector Element instruction" and through nothing
 more than contextual
 augmentation the Scalar ISA *becomes* the Vector ISA.
@@ -285,8 +288,11 @@ the Instruction Decode
 phase is greatly simplified, reducing design complexity and leaving
 plenty of headroom for further expansion.
 
+[[!img "svp64-primer/img/power_pipelines.svg" ]]
+
 Remarkably this is not a new idea.  Intel's x86 `REP` instruction
-gives the base concept, but in 1994 it was Peter Hsu, the designer
+gives the base concept, and the Z80 had something similar.
+But in 1994 it was Peter Hsu, the designer
 of the MIPS R8000, who first came up with the idea of Vector-augmented
 prefixing of an existing Scalar ISA.  Relying on a multi-issue Out-of-Order Execution Engine,
 the prefix would mark which of the registers were to be treated as
@@ -297,7 +303,8 @@ jammed multiple scalar operations into the Multi-Issue Execution
 Engine.  The only reason that the team did not take this forward
 into a commercial product
 was because they could not work out how to cleanly do OoO
-multi-issue at the time.
+multi-issue at the time (leveraging Multi-Issue is the most logical
+way to exploit the Vector-Prefix concept)
 
 In its simplest form, then, this "prefixing" idea is a matter
 of:
@@ -902,9 +909,7 @@ definitely compelling enough to warrant in-depth investigation.
 
 **Use-case: Matrix and Convolutions**
 
-DRAFT image:
-
-<img src="https://ftp.libre-soc.org/20220614_122128.jpg" width=600 />
+<img src="/openpower/sv/sv_horizontal_vs_vertical.svg" />
 
 First, some important definitions, because there are two different
 Vectorisation Modes in SVP64:
@@ -930,7 +935,7 @@ in full.  Vertical-First may be used to perform a LD/ST within
 the loop, covered by `svstep`, but it is still not ideal.  This
 is where the Snitch and EXTRA-V concepts kick in.
 
-<img src="https://ftp.libre-soc.org/matrix_svremap.jpg" width=600 />
+<img src="/openpower/sv/matrix_svremap.svg" />
 
 Imagine a large Matrix scenario, with several values close to zero that
 could be skipped: no need to include zero-multiplications, but a