[Libre-soc-bugs] [Bug 713] PartitionedSignal enhancement to add partition-context-aware lengths

[bugzilla-daemon at libre-soc.org]

https://bugs.libre-soc.org/show_bug.cgi?id=713

--- Comment #71 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Jacob Lifshay from comment #69)
> reading through what you wrote on the wiki:
> https://libre-soc.org/3d_gpu/architecture/dynamic_simd/shape/
> 
> You appear to want to keep forcing SimdShape into being a Shape, and that
> causes problems with SimdShape's current design...
> 
> SimdShape can't be an instance of Shape as you are trying to do, because
> Shape.width is the width of a nmigen scalar Signal/Value, 

yes, perfect.  that means that any down-casting, in combination with
the underlying Signal (SimdSignal.sig, a private member), perfectly
allows down-casting.

if Signal.cast() or Signal.like() is called, i expect it to grab the
underlying Signal, grab the width, grab the sign, and blat the entirety
of the underlying Signal into the (new) one.

done.

no hassle.

no modifications to nmigen required to get that to work.

this was the whole point of UserValue (and UserCastable), that you
are *required* to provide compliance with Shape().

> when vectorizing
> scalar code, Shape.width ends up being the lane width (excluding padding).
> The problem arises because lanes have different widths for different elwid
> values, so there *isn't* a single consistent integer value for Shape.width.
> Shape.width *is not* the same as SimdShape.width, 

ah.  then this is where you have become confused.  it is *defined* so.
that's the whole basis of PartitionedSignal / SimdSignal, that there
*is* an underlying signal (private member, SimdSignal.sig) which *is*
by definition exactly that.

now, will there be blank unused portions of that underlying Signal named
sig? yes.  is it the job of SimdShape to help identify them? yes.

all of the eq and other functions have been *specifically* designed
around the underlying signal being of length and sign Shape.width
and Shape.signed.

that's the whole point.

> since SimdShape.width is
> the width of the whole SIMD signal, which is, from the perspective of user
> code in an ALU, an arbitrary multiple of Shape.width. That multiplication
> factor is determined by the calling code and can arbitrarily vary (e.g. we
> could decide that we want 256-bit wide SIMD ALUs, or we could decide that we
> want to make a tiny 32-bit cpu and we want 32-bit wide SIMD ALUs (which have
> 0 64-bit lanes, 1 32-bit lane, 2 16-bit lanes, or 4 8-bit lanes)).

yes.  Shape.width == 256.  or Shape.width==32.  downcasting with Value.cast
will pick both of those up.

> A possible solution that keeps SimdShape as a subclass of Shape is to rename
> the current SimdShape.width to something like .simd_width, allowing us to
> instead have SimdShape.width be a SimdMapInt (a subclass of SimdMap and int)
> of lane widths (the .width components of lane_shapes), that would meet the
> semantic requirements of Shape.

uh-uh, that's the wrong way round.  yes it's one of the possibilities, but
it's a mistake: it doesn't allow "clean" downcasting.

the route that you are suggesting would require extensive modification
of nmigen for nmigen to comprehend a new concept: simd_width.

the idea here is *not* to make extensive modifications of nmigen.  we currently
have a ridiculously-small 420-line diff.

no way we're doing extensive nmigen modifications, it would be suicidal for
the project.

-- 
You are receiving this mail because:
You are on the CC list for the bug.