[Libre-soc-dev] Vector Supercomputing ISA and 3D GPU resources

[Richard Wilbur]

> On Sep 14, 2021, at 05:47, lkcl <luke.leighton at gmail.com> wrote:
> 
> Richard if you can drop these onto the main SV page, from "links to actual GPUs" onwards, and any others that you find (no need to add the transcendentals, that's already there) that would be most helpful.
> 
> http://libre-soc.org/openpower/sv

I dropped pretty much the whole thing, (we can coalesce the transcendental treatment) because a lot of it described motivation for decisions.

I do have a couple questions and comments (inline below).

> these are all, deep breath, basically... required reading, *as well as and in addition* to a full and comprehensive deep technical understanding of the Power ISA, in order to understand the depth and background on SVP64 as a 3D GPU and VPU Extension.
> 
> i am keenly aware that each of them is each 300 to 1,000 pages (just like the Power ISA itself).

Thus I am 4000-12000 pages behind in my required reading!

> this is just how it is.

Okay, but it will take awhile to catch up.

[…]
> * Scalar bitmanipulation is justifiable for the exact same reasons the extensions are justifiable for other ISAs. the additional justification for their inclusion where some instructions are already (sort-of) present in VSX is that VSX is not mandatory, and VSX too high a price to pay at the Embedded SFFS Compliancy Level.

How does this fit with what you were trying to convey?  (Slight edit on the way to the wiki.)

“[…] VSX is not mandatory, and the complexity of implementation of VSX is too high a price to pay at the Embedded SFFS Compliancy Level.”

> * Scalar FP-to-INT conversions, likewise.  ARM has a javascript conversion instruction, Power ISA does not (and it costs a ridiculous 45 instructions to implement, including 6 branches!)

Are we suggesting that ARM added an instruction to its ISA specifically to support a particular programming language?  Furthermore, I find it very difficult to believe that javascript is the only language which would need to convert FP-to-INT.  I can only imagine javascript being the foremost user of such an instruction if the processor was being specifically designed and optimized to run javascript and the rules of javascript’s conversion from FP-to-INT were significantly different from those in other languages.

[…]
> * Cray ISA
>   http://www.bitsavers.org/pdf/cray/CRAY_Y-MP/HR-04001-0C_Cray_Y-MP_Computer_Systems_Functional_Description_Jun90.pdf

Should we consider grabbing a local copy of the historical documents (which by their very nature won’t be subject to change but might lose their hosting)?

> * RISK5 RVV
> https://github.com/riscv/riscv-v-spec

“Freud, where are you?”  I’m pretty sure Sigmund is hiding around here somewhere.;>)

Drawing attention to the RISKs of the architecture in a subtle way?  I was pretty sure it was spelled, “RISC-V”, or something like that.

> * Mitch Alsup's MyISA 66000 Vector Processor ISA Manual is available from Mitch on direct contact with him.  it is a different approach from the others, which may be termed "Cray-Style Horizontal-First" Vectorisation.  66000 is a *Vertical-First* Vector ISA.


> The term Horizontal or Vertical alludes to the Matrix "Row-First" or "Column-First" technique, where:
> 
> * Horizontal-First processes all elements in a Vector before moving on to the next instruction
> * Vertical-First processes *ONE* element per instruction, and requires loop constructs to explicitly step to the next element.
> 
> * MyISA is Vertical by design.
> * Cray, SX Aurora, RVV, are Horizontal by design
> * SVP64 supports both.
> 
> l.
>