From: lkcl Date: Wed, 14 Sep 2022 20:46:11 +0000 (+0100) Subject: (no commit message) X-Git-Tag: opf_rfc_ls005_v1~438 X-Git-Url: https://git.libre-soc.org/?a=commitdiff_plain;h=082f344298db0175e1bf62d8747e51f081ab5c3a;p=libreriscv.git --- diff --git a/openpower/sv/rfc/ls001.mdwn b/openpower/sv/rfc/ls001.mdwn index 431bc4306..08f6743f9 100644 --- a/openpower/sv/rfc/ls001.mdwn +++ b/openpower/sv/rfc/ls001.mdwn @@ -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