**Revision History**
* v0.00 05may2021 first created
+* v0.01 06may2021 initial first draft
**Table of Contents**
# Why in the 2020s would you invent a new Vector ISA
+*(The short answer: you don't. Extend existing technology: on the shoulders of giants)*
+
Inventing a new Scalar ISA from scratch is over a decade-long task
including simulators and compilers: OpenRISC 1200 took 12 years to
mature. A Vector or Packed SIMD ISA to reach stable *general-purpose*
AMD, MIPS, Sun Microsystems, SGI, Cray, and many more. (*Hand-crafted
assembler and direct use of intrinsics is the Industry-standard norm
to achieve high-performance optimisation where it matters*).
-Rather: GPUs
-have ultra-specialist compilers (CUDA) that are designed from the ground up
+GPUs fill this void both in hardware and software terms by having
+ultra-specialist compilers (CUDA) that are designed from the ground up
to support Vector/SIMD parallelism, and associated standards
(SPIR-V, Vulkan, OpenCL) managed by
the Khronos Group, with multi-man-century development committment from
this task, and what, in Computer Science, actually needs solving?
First hints are that whilst memory bitcells have not increased in speed
-since the 90s (around 150 mhz), increasing the datapath widths has allowed
+since the 90s (around 150 mhz), increasing the bank width, striping, and
+datapath widths and speeds to the same has allowed
significant apparent speed increases: 3200 mhz DDR4 and even faster DDR5,
and other advanced Memory interfaces such as HBM, Gen-Z, and OpenCAPI,
all make an effort (all simply increasing the parallel deployment of
Aspex Microelectronics, Elixent, these are parallel processing companies
that very few have heard of, because their software stack was so
specialist that it required heavy investment by customers to utilise.
-D-Matrix and Graphcore are a modern incarnation of the exact same
+D-Matrix, a Systolic Array Processor, is a modern incarnation of the exact same
"specialist parallel processing" mistake, betting heavily on AI with
Matrix and Convolution Engines that can do no other task. Aspex only
survived by being bought by Ericsson, where its specialised suitability
for massive wide Baseband FFTs saved it from going under.
The huge risk is that any "better
AI mousetrap" created by an innovative competitor
-that comes along will quickly render both D-Matrix and
-Graphcore's approach obsolete.
+that comes along quickly renders a too-specialist design obsolete.
NVIDIA and other GPUs have taken a different approach again: massive
parallelism with more Turing-complete ISAs in each, and dedicated
ARM, Intel, AMD, since the 90s (over 3 decades) whereby SIMD, an
Order(N^6) opcode proliferation nightmare, with its mantra "make it
easy for hardware engineers, let software sort out the mess" literally
-overwhelming programmers. Specialists charging
+overwhelming programmers with thousands of instructions. Specialists charging
clients for assembly-code Optimisation Services are finding that AVX-512,
to take an
example, is anything but optimal: overall performance of AVX-512 actually
* RISC-V, touted as "Open" but actually strictly controlled under
Trademark License: too new to have adequate patent pool protection,
as evidenced by multiple adopters having been hit by patent lawsuits.
+ (Agreements between RISC-V *Members* to not engage in patent litigation
+ does nothing to stop third party patents that *legitimately pre-date*
+ the newly-created RISC-V ISA)
* MIPS, SPARC, ARC, and others, simply have no viable ecosystem.
* Power ISA: protected by IBM's extensive patent portfolio for Members
of the OpenPOWER Foundation, covered by Trademarks, permitting
to use the x86 ISA need only look at Transmeta, SiS, the Vortex x86,
and VIA EDEN processors, and see how they fared.
* s390, IBM's mainframe ISA. Nowhere near as well-known as x86 lawsuits,
- but the 800lb Gorilla Syndrome seems not to have deterred one
+ but the 800lb "Corporate Gorilla Syndrome" seems not to have deterred one
particularly disingenuous group from performing illegal
Reverse-Engineering.
* It has a 25-year software ecosystem, with RHEL, Fedora, Debian
and more.
+* Amongst many other features
+ it has Condition Registers which can be used by Branches, greatly
+ reducing pressure on the main register files.
* IBM's extensive 20+ years of patents is available, royalty-free,
to protect implementors as long as they are also members of the
OpenPOWER Foundation
* IBM designed and maintained the Power ISA as a Supercomputing
- class ISA from its inception.
+ class ISA from its inception over 25 years ago.
* Coherent distributed memory access is possible through OpenCAPI
* Extensions to the Power ISA may be submitted through an External
RFC Process that does not require membership of OPF.
compared to a well-designed Cray-style Vector ISA with a `setvl`
instruction.
+*Packed SIMD looped algorithms actually have to
+contain multiple implementations processing fragments of data at
+different SIMD widths: Cray-style Vectors have just the one, covering not
+just current architectural implementations but future ones with
+wider back-end ALUs as well.*
+
Assuming then that variable-length Vectors are obviously desirable,
it becomes a matter of how, not if. Both Cray and NEC SX Aurora
went the way of adding explicit Vector opcodes, a style which RVV
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? Then, the Instruction Decode
+or prefix that augments its behaviour? Make "Scalar instruction"
+synonymous with "Scalar instruction" and through contextual
+augmentation the Scalar ISA *becomes* the Vector ISA.
+Then, by not having to have any Vector instructions at all,
+the Instruction Decode
phase is greatly simplified, reducing design complexity and leaving
plenty of headroom for further expansion.
go as low as 8-bit arithmetic, even 8-bit Floating-Point for
high-performance AI. Rather than waste opcode space adding all
such operations at different bitwidths, let the prefix
- *redefine* the element width.
+ *redefine* (override) the element width, without actually altering
+ the Scalar ISA at all.
* "Reordering" of the assumption of linear sequential element
access, for Matrices, rotations, transposition, Convolutions,
DCT, FFT, Parallel Prefix-Sum and other common transformations
All of these things come entirely from "Augmentation" of the Scalar operation
being prefixed: at no time is the Scalar operation significantly
altered.
-From there, several more "Modes" can be added, including saturation,
-which is needed for Audio and Video applications, "Reverse Gear"
+From there, several more "Modes" can be added, including
+
+* saturation,
+which is needed for Audio and Video applications
+* "Reverse Gear"
which runs the Element Loop in reverse order (needed for Prefix
-Sum), and more.
+Sum)
+* Data-dependent Fail-First, which emerged from asking the simple
+ question, "If modern Vector ISAs have Load/Store Fail-First,
+ and the Power ISA has Condition Codes, why not make Conditional
+ early-exit from Arithmetic operation looping?"
+* over 500 Branch-Conditional Modes emerge from application of
+ Boolean Logic in a Vector context, on top of an already-powerful
+ Scalar Branch-Conditional/Counter instruction
**What is missing from Power Scalar ISA that a Vector ISA needs?**
emergent characteristic from the carry-in, carry-out capability of
Power ISA `adde` instruction. `sv.adde` as a BigNum add
naturally emerges from the
- sequential chaining of these scalar instructions.
+ sequential carry-flag chaining of these scalar instructions.
* The Condition Register Fields of the Power ISA make a great candidate
for use as Predicate Masks, particularly when combined with
Vectorised `cmp` and Vectorised `crand`, `crxor` etc.
One deliberate decision in SVP64 involves Predication. Typical Vector
ISAs have quite comprehensive arithmetic and logical operations on
-Predicate Masks, and if CR Fields were the only predicates in SVP64
+Predicate Masks, and it turns out, unsurprisingly, that the Scalar Integer
+side of Power ISA already has most of them.
+If CR Fields were the only predicates in SVP64
it would put pressure on to start adding the exact same arithmetic and logical
-operations that already exist in the Integer opcodes.
+operations that already exist in the Integer opcodes, which is less
+than desirable.
Instead of taking that route the decision was made to allow *both*
Integer *and* CR Fields to be Predicate Masks, and to create Draft
instructions that provide better transfer capability between CR Fields
and controlled by each instruction is enormous, and leaves the
Decode and Issue Engines idle, as well as the L1 I-Cache. With
programs being smaller, chances are higher that they fit into
-L1 Cache, or that the L1 Cache may be made smaller.
+L1 Cache, or that the L1 Cache may be made smaller: either way
+is a considerable O(N^2) power-saving.
Even a Packed SIMD ISA could take limited advantage of a higher
bang-per-buck for limited specific workloads, as long as the
Additional savings come in the form of `SVREMAP`. This is a hardware
index transformation system where the normally sequentially-linear
-element access may be "Re-Mapped" to limited but algorithmic-tailored
+Vector element access may be "Re-Mapped" to limited but algorithmic-tailored
commonly-used deterministic schedules, for example Matrix Multiply,
DCT, or FFT. A full in-register-file 5x7 Matrix Multiply or a 3x4 or
-2x6 may be performed in as little as 4 instructions, one of which
+2x6 with optional *in-place* transpose, mirroring or rotation
+on any source or destination Matrix
+may be performed in as little as 4 instructions, one of which
is to zero-initialise the accumulator Vector used to store the result.
If addition to another Matrix is also required then it is only three
instructions. Not only that, but because the "Schedule" is an abstract
the SVP64 concept could be expanded to Coherent Distributed Memory,
This astoundingly powerful concept is explored in the next section.
-# Coherent Deterministic Hybrid Distributed Memory-Processing
+# Coherent Deterministic Hybrid Distributed In-Memory Processing
It is not often that a heading in an article can legitimately
-contain quite so many comically-chain buzzwords, but in this section
-it is justified. As hinted at in the first section, the last time
+contain quite so many comically-chained buzzwords, but in this section
+they are justified. As hinted at in the first section, the last time
that memory was the same speed as processors was the Pentium III
and Motorola 88100 era: 133 and 166 mhz SDRAM was available, and
CPUs were about the same rate. DRAM bitcells *simply cannot exceed
these rates*, yet the pressure from Software Engineers is to
make *sequential* algorithm processing faster and faster because
-parallelising of algorithms is simply too difficult to master and always
+parallelising of algorithms is simply too difficult to master, and always
has been. Thus whilst DRAM has to go parallel (like RAID Striping) to
keep up, CPUs are now at 8-way Multi-Issue 5 ghz clock rates and
are at an astonishing four levels of cache (L1 to L4).
It should therefore come as no surprise that attempts are being made
to move (distribute) processing closer to the DRAM Memory, firmly
-on the *opposite* side of the main CPU's L1/2/3/4 Caches. However
+on the *opposite* side of the main CPU's L1/2/3/4 Caches,
+where a simple `LOAD-COMPUTE-STORE-LOOP` workload easily illustrates
+why this approach is compelling. However
the alarm bells ring here at the keyword "distributed", because by
-moving the processing down next to the Memory, the speed of any
-of the parallel Processing Elements (PEs) has dropped
-by almost two orders of magnitude,
-the simplicity has for pure pragmatic reasons to drop by several
-orders of magnitude. Things that the average "sequential algorithm"
+moving the processing down next to the Memory, even onto
+the same die as the DRAM, the speed of any
+of the parallel Processing Elements (PEs) would likely drop
+by almost two orders of magnitude (5 ghz down to 150 mhz),
+the simplicity of each PE has, for pure pragmatic reasons,
+to drop by several
+orders of magnitude as well.
+Things that the average "sequential algorithm"
programmer
takes for granted such as SMP, Cache Coherency, Virtual Memory,
-spinlocks (atomic locking), all of these are either outright gone
+spinlocks (atomic locking, mutexes), all of these are either outright gone
or expected that the programmer shall explicitly contend with
-(even if that programmer is the Compiler Developer).
+(even if that programmer is the Compiler Developer). There's definitely
+not going to be a standard OS: the PEs will be too basic, too
+resource-constrained, and definitely too busy.
To give an extreme example: Aspex's Array-String Processor, which
was 4096 2-bit SIMD PEs each with 256 bytes of Content Addressable
-Memory was capable of literally a hundred-fold improvement in
+Memory, was capable of literally a hundred-fold improvement in
performance over Scalar CPUs such as the Pentium III of its era,
-all on a 3.5 watt budget at only 250 mhz in 130 nm. Yet to take
+all on a 3 watt budget at only 250 mhz in 130 nm. Yet to take
proper advantage of its capability required an astounding 5-10
-*days* per line of assembly code. 20 lines of optimised
-Assembler taking six months to write can in no way be termed
+*days* per line of assembly code because multiple versions of
+an algorithm had to be hand-crafted then compared, and only
+the best one selected: all others discarded. 20 lines of optimised
+Assembler taking three to six months to write can in no way be termed
"productive", yet this extreme level of unproductivity is an inherent
side-effect of going down the parallel-processing rabbithole.
**ZOLC: Zero-Overhead Loop Control**
+Zero-Overhead Looping is the concept of automatically running a set sequence
+of instructions for a predetermined number of times, without requiring
+a branch. This is slightly different from using Power ISA `bc` in `CTR`
+(Counter) Mode, because in ZOLC the branch-back is automatic.
+
The simplest longest commercially successful deployment of Zero-overhead looping
has been in Texas Instruments TMS320 DSPs. Up to fourteen sub-instructions
within the VLIW word may be repeatedly deployed on successive clock
cycles until a countdown reaches zero. This extraordinarily simple
-concept needs no branches, no complex Register Hazard
-Management because it is down to the programmer (or, the compiler),
-to ensure data overlaps do not occur.
+concept needs no branches, and has no complex Register Hazard
+Management in the hardware
+because it is down to the programmer (or, the compiler),
+to ensure data overlaps do not occur. Careful crafting of those
+14 instructions can keep the ALUs 100% occupied for sustained periods,
+and the iconic example for which the TI DSPs are renowned
+is that an entire inner loop for large FFTs
+can be done with that one VLIW word: no stalls, no stopping, no fuss.
+
+The key aspect of these
+very simplistic countdown loops as far as we are concerned:
+is: *they are deterministic*.
+
+Zero-Overhead Loop Control takes this basic "single loop" concept
+way further: both nested loops and conditional exit are included,
+but also arbitrary control-jumping from the current inner loop
+out to an entirely different loop, all based on conditions determined
+dynamically at runtime.
+
+Even when deployed on as basic a CPU as a single-issue in-order RISC
+core, the performance and power-savings were astonishing: between 20
+and **80%** reduction in algorithm completion times were achieved compared
+to a more traditional branch-speculative in-order RISC CPU. MPEG
+Decode, the target algorithm specifically picked by the researcher
+due to its high complexity with 6-deep nested loops and conditional
+execution that frequently jumped in and out of at least 2 loops,
+came out with an astonishing 43% improvement in completion time. 43%
+less instructions executed is an almost unheard-of level of optimisation:
+most ISA designers are elated if they can achieve 5 to 10%. The reduction
+was so compelling that ST Microelectronics put it into commercial
+production in one of their embedded CPUs, the ST120 DSP-MCU.
+
+The kicker: when implementing SVP64's Matrix REMAP Schedule, the VLSI
+design of its triple-nested for-loop system
+turned out to be remarkably similar to the
+core nested for-loop engine of ZOLC. In hindsight this should not
+have come as a surprise, because both are basically nested for-loops
+that do not need branches to issue instructions.
+
+The important insight is, however, that if ZOLC can be general-purpose
+and apply deterministic nested looped instruction
+schedules to more than just registers
+(unlike SVP64 in its current incarnation) then so can SVP64.
**OpenCAPI and Extra-V**
+OpenCAPI is a deterministic high-performance, high-bandwidth, low-latency
+cache-coherent Memory-access Protocol that is integrated into IBM's Supercomputing-class POWER9 and POWER10 processors. POWER10 *only*
+has OpenCAPI Memory interfaces, and requires an OMI-to-DDR4/5 Bridge PHY
+to connect to standard DIMMs.
+
+Extra-V appears to be a remarkable research project based on OpenCAPI that,
+by assuming that the map of edges (excluding the actual data)
+in any given arbitrary data graph
+could be kept by the main CPU in-memory, could distribute and delegate
+a limited-capability deterministic but most importantly *data-dependent*
+node-walking schedule actually right down into the memory itself (on the other side of that L1-4 cache barrier). A miniature processor
+(non-Turing-complete) analysed
+the data it had read (at the Memory), and determined if it should
+notify the main processor that this "Node" is worth investigating,
+or if the Graph node-walk should split in a different direction.
+Thanks to the OpenCAPI Standard, which takes care of Virtual Memory
+abstraction, locking, and cache-coherency, many of the nightmare problems
+of other more explicit parallel processing paradigms disappear.
+
+The similarity to ZOLC should not have gone unnoticed: where ZOLC
+has nested conditional for-loops Extra-V appears to have just the
+one conditional for-loop, but the key strategically-crucial
+part of this multi-faceted puzzle is that due to the deterministic and
+coherent nature of Extra-V, the processing of the loops, which
+requires a tiny non-Turing-Complete processor, is not
+done close to or by the main CPU at all: it is
+*embedded right next to the memory*.
+
+The similarity to the D-Matrix Systolic Array Processing, Aspex Microelectronics
+Array-String Processing, and Elixent 2D Array Processing, should
+also not have gone unnoticed. All of these solutions utilised
+or utilise
+a more comprehensive Turing-complete von-Neumann "Management Core"
+to coordinate data passed in and out of PEs: none of them have or
+had something
+as powerful as OpenCAPI as part of that picture.
+
+The fact that Neural Networks may be expressed as arbitrary Graphs,
+and comprise Sparse Matrices, should also have been noted by the reader
+interested in AI.
+
**Snitch**
+Snitch is an elegant Memory-Coherent Barrel-Processor where registers
+become "tagged" with a Memory-access Mode that went out of fashion
+over forty years ago: Load-then-Auto-Increment. Expressed in c as
+`src = *x++`, and requiring special Address Registers (PDP-11, 68000),
+thanks to the RISC paradigm having gone too far,
+the efficiency and effectiveness
+of these Load-Store-with-Increment instructions has been
+forgotten until Snitch.
+
+What the designers did however was not to add new Load-Store
+or Arithmetic instructions to RISC-V, but instead to "mark"
+registers with a tag. These tags tell the CPU: when you are asked to
+carry out
+an add instruction on r6 and r7, do not take r6 or r7 from the register
+file, instead please perform a Cache-coherent Load-with-Increment
+on each, using special Address Registers for each. Each new use
+of r6 therefore brings in an entirely new value *directly from
+memory*. Likewise on the second operand, r7, and likewise on
+the destination result which can be an automatic Coherent
+Store-and-increment
+directly into Memory. In essence:
+
+*The act of "reading" or "writing" a register has been decoupled
+and intercepted, then connected transparently to a completely
+separate Coherent Memory Subsystem*
+
+On top of a barrel-architecture the slowness of Memory access
+was not a problem because the Deterministic nature of classic
+Load-Store-Increment can be compensated for by having 8 Memory
+accesses scheduled underway and interleaved in a time-sliced
+fashion with an FPU that is correspondingly 8 times faster than
+the Coherent Memory accesses.
+
+This design is reminiscent of the early Vector Processors
+of the late 1950s and early 1960s, which also critically relied
+on implicit auto-increment addressing.
+The [CDC STAR-100](https://en.m.wikipedia.org/wiki/CDC_STAR-100)
+for example was specifically designed as a Memory-to-Memory Vector
+Processor. The barrel-architecture of Snitch neatly
+solves one of the inherent problems of those early designs (a mismatch
+with memory
+speed) and the presence of a full register file (non-tagged,
+normal, standard scalar registers) caters for a
+second limitation of pure Memory-based Vector Processors: temporary
+variables needed in the computation of intermediate results, which
+also had to go through memory, put
+an awfully high artificial load on Memory bandwidth.
+
+The similarity to SVP64 should be clear: SVP64 Prefixing and the
+associated REMAP system is just another form of register "tagging"
+that augments what was formerly designated by its original authors
+as "just a Scalar ISA", tagging allows for dramatic implicit alteration
+with advanced behaviour not previously envisaged.
+
+What Snitch brings to the table therefore is a further illustration of
+the concept introduced by Extra-V: where Extra-V brought information
+about Sparse-Distributed Data to the attention of the main CPU in
+a coherent fashion *without the CPU having to ask for it*, Snitch
+demonstrates a classic LOAD-COMPUTE-STORE cycle in the same
+distributed coherent manner, and does so with dramatically-reduced
+power consumption.
+
+**Bringing it all together**
+
+At this point we are well into a future revision of SVP64, one that
+clearly has some startlingly powerful potential: Supercomputing-class
+Multi-Issue Vector Engines kept 100% occupied in a 100% long-term
+sustained fashion with reduced complexity, reduced power consumption
+and reduced completion time, thanks to Deterministic Coherent Scheduling
+of the data fed in and out, or even moved down next to Memory.
+
+This last part is where it normally gets hair-raising, but as ZOLC shows
+there is no reason at all why even complex algorithms such as MPEG cannot
+be run in a partially-deterministic manner, and anything that is
+deterministic can be Scheduled, coherently. Combine that with OpenCAPI
+which solves the many issues associated with SMP Virtual Memory and so on
+yet still allows Cache-Coherent Distributed Memory Access, and what was
+previously an intractable Computer Science problem for decades begins to
+look like there is a potential solution.
+
+The Deterministic Schedules created by ZOLC should even be possible to identify their
+suitability for full off-CPU distributed processing, as long as OpenCAPI
+is integrated into the mix. What a compiler - or even the hardware -
+will be looking out for is a Basic Block of instructions that:
+
+* begins with a LOAD (to be handled by OpenCAPI)
+* contains some instructions that a given PE is capable of executing
+* ends with a STORE (again: OpenCAPI)
+
+For best results that would be wrapped with a Zero-Overhead Loop
+(which is offloaded - in full - down to the PE), where
+the Compiler (or hardware at runtime) could easily identify, in advance,
+the full range of Memory Addresses that the Loop is to encounter. Copies
+of loop-invariant data would need to be passed down to the remote PE:
+again, for simple-enough Basic Blocks, with assistance from the Compiler,
+loop-invariant inputs are easily identified. Parallel Processing
+opportunities should also be easy enough to create, simply by farming out
+different parts of a given Deterministic Zero-Overhead Loop to
+different PEs based on their proximity, bandwidth or ease of access to
+given Memory.
+
+The importance of OpenCAPI in this mix cannot be underestimated, because
+it will be the means by which the main CPU coordinates its activities
+with the remote PEs, ensuring that LOAD/STORE Memory Hazards are not
+violated. It should also be straightforward to ensure that the offloading
+is entirely transparent to the developer, in fact this is a hard requirement
+because at any given moment there is the possibility that the PEs may be
+busy and it is the main CPU that has to complete the Processing Task itself.
+
+It is also important to note that we are not necessarily talking about
+the Remote PEs executing the Power ISA, but if they do so it becomes
+much easier for the main CPU to take over in the event that PEs are
+currently occupied. Plus, the twin lessons that inventing ISAs, even
+a small one, is hard (mostly in compiler writing) and how complex
+GPU Task Scheduling is, are being heard loud and clear.
+
+Put another way: if the PEs run a foriegn ISA, then the Basic Blocks embedded inside the ZOLC Loops must be in that ISA and therefore:
+
+* In order that the main CPU can execute the same sequence if necessary,
+ the CPU must support dual ISAs: Power and PE **OR**
+* There must be a JIT binary-translator which either turns PE code
+ into Power ISA code or vice-versa **OR**
+* The compiler dual-compiles the original source code, and embeds
+ both a Power binary and a PE binary into the ZOLC Basic Block **OR**
+* All binaries are stored in an Intermediate Representation
+ (LLVM-IR, SPIR-V) and JIT-compiled on-demand.
+
+All of these would work, but it is simpler and a lot less work
+just to have the PEs
+execute the exact same ISA (or a subset of it). If however the
+concept of Hybrid PE-Memory Processing were to become a JEDEC Standard,
+which would increase adoption and reduce cost, a bit more thought
+is required here because ARM or Intel or MIPS might not necessarily
+be happy that a Processing Element has to execute Power ISA binaries.
+At least the Power ISA is much richer, more powerful, still RISC,
+and is an Open Standard, as discussed in a earlier sections.
+
+# Transparently-Distributed Vector Processing
+
+It is very strange to the author to be describing what amounts to a
+"Holy Grail" solution to a decades-long intractable problem that
+mitigates the anticipated end of Moore's Law: how to make it easy for
+well-defined workloads, expressed as a perfectly normal
+sequential program, compiled to a standard well-known ISA, to have
+the potential of being offloaded transparently to Parallel Compute Engines,
+all without the Software Developer being excessively burdened with
+a Parallel-Processing Paradigm that is alien to all their experience
+and training, as well as Industry-wide common knowledge.
+
+Will it be that easy? ZOLC is, honestly, in its current incarnation,
+not that straightforward: programs
+have to be "massaged" by tools that insert intrinsics into the
+source code, in order to identify the Basic Blocks that the Zero-Overhead
+Loops can run. Can this be merged into standard gcc and llvm
+compilers? As intrinsics: of course. Can it become part of auto-vectorisation? Probably,
+if an infinite supply of money and engineering time is thrown at it.
+Is a half-way-house solution of compiler intrinsics good enough?
+Intel, ARM, MIPS, Power ISA and RISC-V have all already said "yes" on that,
+for several decades, and advanced programmers are comfortable with the
+practice.
+
+**Roadmap summary of Advanced SVP64**
+
+The future direction for SVP64, then, is:
+
+* To overcome its current limitation of REMAP Schedules being
+ restricted to Register Files, leveraging the Snitch-style
+ register interception "tagging" technique.
+* To adopt ZOLC and merge REMAP Schedules into ZOLC
+* To bring OpenCAPI Memory Access into ZOLC as a first-level
+ concept that mirrors Snitch's Coherent Memory interception
+* To add the Graph-Node Walking Capability of Extra-V
+ to ZOLC / SVREMAP
+* To make it possible, in a combination of hardware and software,
+ to easily identify ZOLC / SVREMAP Blocks
+ that may be transparently pushed down closer to Memory, for
+ localised distributed parallel execution, by OpenCAPI-aware PEs,
+ exploiting both the Deterministic nature of ZOLC / SVREMAP
+ combined with the Cache-Coherent nature of OpenCAPI,
+ to the maximum extent possible.
+* To make the exploitation of this powerful solution as simple
+ and straightforward as possible for Software Engineers to use,
+ in standard common-usage compilers, gcc and llvm.
+* To propose extensions to Public Standards that allow all of
+ the above to become part of everyday ubiquitous mass-volume
+ computing.
+
+Even the first of these - merging Snitch-style register tagging
+into SVP64 - would
+expand SVP64's capability for Matrices, currently limited to
+around 5x7 to 6x6 Matrices and constrained by the size of
+the register files (128 64-bit entries), to arbitrary (massive) sizes.
+
+Bottom line is that there is a clear roadmap towards solving a long
+standing problem facing Computer Science and doing so in a way that
+reduces power consumption reduces algorithm completion time and reduces
+the need for complex hardware microarchitectures in favour of much
+smaller distributed coherent Processing Elements.
projects / libreriscv.git / blobdiff