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

lkcl luke.leighton at gmail.com
Tue Sep 14 22:01:48 UTC 2021

On September 14, 2021 9:23:07 PM UTC, Richard Wilbur <richard.wilbur at gmail.com> wrote:

>> 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

oh ok :)

>> 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!

i skimmed them, i was looking e.g. in SX Aurora, what do the Vector Reduce instructions look like, how do they compare to Cray and RVV, what is missing what.

>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.)

i was reluctant to spell it out directly, but:

* Packed SIMD is just awful for general purpose compute (i know you have personally had nightmare experiences with it), but perfect for e.g. stereo audio data or other data where the width matches PERFECTLY with the application
* the Sigarch article puts it much more diplomatically
* the cost in time and effort, to create something that would continue to make programmers lives a living hell, every time i try to come up with a reason to implement it i can't countenance it
* the cost in silicon gates, adding 750 instructions, quadrupling the numbers, is also too high
* the cost in the decoder alone is so high you need a * 2 stage* pipeline!

that's one plus [in a specialist area] and everything else is minuses.

>Are we suggesting that ARM added an instruction to its ISA specifically
>to support a particular programming language? 

no, we'rw not suggesting, at all, we're *saying* that's precisely what they did.

this is pretty normal practice for ISA design.  find a performance / power black spot, identify its usage, design instruction, check increase in performance, reduction in power consumption / {insert other benefit}, implement.


> Furthermore, I find it
>very difficult to believe that javascript is the only language which
>would need to convert FP-to-INT. 

see fp int page on wiki.

>> * Cray ISA
>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)?



More information about the OpenPOWER-HDL-Cores mailing list