[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 #87 from Jacob Lifshay <programmerjake at gmail.com> ---
(In reply to Luke Kenneth Casson Leighton from comment #85)
> (In reply to Jacob Lifshay from comment #82)
> > > we need - and other users will expect - that Casting will "just work".
> > > SimdSignal should be castable to Signal and all bits *directly*
> > > copied (including unused padding partitions) seamlessly at the bitlevel.

Ok, I read "casting" as "Signal.eq", and didn't think beyond that, my bad.

> > Well, SimdSignal is *fundamentally* incompatible with nmigen Value/Signal,
> 
> no it is not!  it's already been implemented, and *is* compatible!
> 
> > since nmigen expects Values to act like a single scalar value, 
> 
> no.  whitequark *wants* to *define* nmigen to be thus.

And I agree with her there, nmigen has always been scalar, where each Value is
a single value, not a list of values. Basically everybody expects nmigen's
Value to be a scalar. If you insist on rewriting nmigen to change that
fundamental assumption, you'll end up with a different language, that is called
nmigen only because you are confusing your fundamental assumption-breaking
changes as being compatible with nmigen, and you can sorta get away with it
because nmigen is written in Python and only checks some of the typing.

I'm advocating for making a set of classes SimdSignal, SimdValue, SimdShape,
etc. that effectively is a Simd-ified version of nmigen Signal, Value, Shape,
etc. *and their named differently* because they fundamentally are lists of
scalars, not single scalars.

>  whitequark,
> just before banning me from participation on #nmigen,

oh, sad and surprised to hear that...I'll wait a while and then see if I can
convince whitequark to let you back, since your behavior wasn't bad enough to
warrant a ban imho (unless something happened that I didn't see), though
apologising for making mwk feel as if you're talking down to them wouldn't hurt
(apologising for what they percevied as condescending, which is not what you
intended). pointing out that they're being rude, while true, won't actually
help everyone get along. pointing out and asking people to not be rude is
mostly whitequark's responsibility, not yours, since she is the channel
moderator. Hopefully, my pointing this out will help everyone, my intention
isn't to hurt you but help you realize a potentially better way to get along
with everyone.

> made it bluntly
> clear, as part of reneging on the agreement back in april, that this
> decision was made.
> 
> whether the code *can* support full abstraction (which with a mere
> 420-line diff, it can), whitequark unilaterally decided that that was
> completly irrelevant.

Well, I'm saying your 90% of the way there, but the last 10% of abstraction is
the harder part...it's easier and more consistent to just have a separate API
that mirrors nmigen's API, allowing unmodified nmigen to work with our code, as
well as making our code much clearer. This wouldn't require that much effort,
since we can use most of the existing PartitionedSignal code with minor
modifications and renaming.

> > whereas
> > SimdSignal acts like a *list* of scalar values -- aka. a Vector.
> 
> yes.  and therefore the entire suite of operators of SimdSignal can be
> *defined* to act in list-form, at every single level in the entirety of ast.*
> operations.

I'm saying the existing design only does a 90% job, it covers list-form +, -,
*, &, ^, |, .eq, etc.

It does *not* cover Shape.width, Signal.like, etc.

I'm saying we should finish off getting to 100% of the API looking like a
transparently vectorized (aka SIMT) version of nmigen Shape/Signal/Value/etc.,
just with different names, since that will make it much easier to
use/understand. Note that Shape.width (lane width) not being a plain integer
comes from lanes being XLEN-width, not from being vectorized. those are
orthogonal unrelated changes. We could have a totally scalar Signal/Value/etc.
that are all XLEN-ified, that would require modifying Shape.width to be
multivalued. We could also vectorize our totally 64-bit-only code, that would
leave Shape.width == 64 (since that's the *element* width), even if a vector
was 256-bits wide.

+----------------+---------------+-------------------------------------------+
| XLEN-ification | Vectorization |                                           |
+================+===============+===========================================+
| No             | No            | Original Scalar code;                     |
|                |               | Shape.width == 64                         |
+----------------+---------------+-------------------------------------------+
| No             | Yes           | SimdShape.width==64,                      |
|                |               | SimdShape.simd_width==128                 |
+----------------+---------------+-------------------------------------------+
| Yes            | No            | XLShape.width==XLEN==                     |
|                |               |     XLMap({I8:8,I16:16,I32:32,I64:64})    |
+----------------+---------------+-------------------------------------------+
| Yes            | Yes           | SimdShape.width==XLEN==                   |
|                |               |     SimdMap({I8:8,I16:16,I32:32,I64:64}), |
|                |               | SimdShape.simd_width==128                 |
+----------------+---------------+-------------------------------------------+

> have you run the unit test and / or contributed to the individual modules?

Yes, I have -- don't forget that I'm the one who originally wrote the
PartitionedAdd and PartitionedMultiply -- the inspiration for this whole thing.

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