[Libre-soc-dev] [RFC] svp64 "source zeroing" makes no sense

[Luke Kenneth Casson Leighton]

On Tuesday, March 23, 2021, Richard Wilbur <richard.wilbur at gmail.com> wrote:

>
> What "predicate mask bits" will the "Dynamic Partitioned ALUs" be
> receiving?


one option is: absolutely none whatsoever.  you may not have realised the
significance of "bypass the ALU entirely".

conceptually however for 8 16 and 32 bit the bytelevel write-enable lines
are "expanded predicate mask bits only not really".  anything passed in to
the ALUs in positions which are not going to be written we simply don't
give a damn.

when clock gating becomes possible this is an entirely different matter.
each dynamic lane *at the byte level* will need gating.



>
> >
> > Will the mask size be related to the partitioned
> > > size of the ALU?
> > >
> >
> > not at all.
> > https://libre-soc.org/3d_gpu/architecture/dynamic_simd/?updated
>
> Ok.  I read that and a bit more.  I think I have a conceptual
> understanding of the dynamically partitioned ALUs.  Very cool.


frickin awesome more like.  saves hugely on gate count and massively
reduces complexity.


> a masked equivalent would be handy.
>
> What do you mean?


start from a position other than the start.  basically shift the value
down, trash N bits, then count.


>
>
> What information is stored in SVSTATE?


 https://libre-soc.org/openpower/sv/sprs/

https://git.libre-soc.org/?p=soc.git;a=blob;f=src/soc/sv/svstate.py;hb=HEAD


> Where in the loop is the valid exit point if an interrupt occurs?


at any time.  it's a Sub-Program-Counter and should be treated as such.


>
> While shovelling snow and ice this morning


as you do.  hey it's better than shovelling s*** at any temperature


> (storm last night) I
> realized that the only things the module I proposed needs to recover
> state are the initial predication mask (our starting point)


which is re-read on restarting the instruction if it's an INT predicate.


> and the
> last value of the step.


 and the sub-step.  and the dest step.  see SVSTATE.

> this can however get complicated when dynamic SIMD back-ends are involved.
>
> Yes, having read a bit about the dynamic SIMD it sounds like
> predication could be complicated in that instance.  It seems that
> dynamic SIMD determines how you process an operand


operands plural.


>  once you get it and
> predication has to do with which operand we send and where we store
> the result.


correct.


>
> Good choice!  I am planning to read about the Cray Vector system soon
> (today).
>
>
it's fun (awesome) but different.  Cray vectors actually have vector
registers and therefore have vector instructions.

in SV there are no vector registers.
just loops that "oh look this sequence can be sent to a massive wide SIMD
backend"

this confuses the hell out of anyone who believes that vector registers are
The One True Way.

l.



-- 
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68