[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 #110 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Jacob Lifshay from comment #87)

> And I agree with her there, nmigen has always been scalar,

not being funny:
stating that you agree with whitequark is actually very dangerous
for the project.  it will be used as ammunition to sabotage what we are
doing.

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

no, false.  did we design totally new Power ISA Scalar v3.0B because of
SVP64?

this is the exact same thing.

the entirety of the nmigen language *becomes* vectorised...
WITHOUT CHANGING THAT LANGUAGE IN ANY WAY


please this is very frustrating that you do not get this or accept it
and keep on advocating massive bodies of unnecessary work as a result.



> that
> is called nmigen only because you are confusing your fundamental
> assumption-breaking 

no confusion. no assumptions are broken.  please study the RFC and read the
code until you undertand properly.

if you do not understand please ask questions instead of continuing
to advocate alternative designs.



> oh, sad and surprised to hear that...I'll wait a while and then see if I can
> convince whitequark to let you back,

i will respond on list

> > 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 actually been pretty easy, just a hell of a lot of work (and to
be honest i am annoyed that, again, you haven't helped with Cat, Repl,
Part, or any of the recent additions, which i asked you to help with)

there's over THIRTY operators.  i really needed your help in implementing
them and you have instead spent considerable time snd resources fighting
every single step of the way to *not* help.  i do not know why.
leaving that aside for you to think about


there are two REALLY complex ones:

* Array (and ArrayProxy).

* ast.Switch aka SimdSignal.__Switch__.

i did the analysis, under bug #458, and whoo, even just the analysis
takes a hell of a lot of explaining.

unfortunately because ast.Switch is the basis of m.If, m.FSM and
m.Switch, i can't provide "full proof" until it's actually 100%
implemented.

i need 1 clear week in which to implement it.

i could have had it finished over 10 days ago if you had not kept
fighting me with alternative designs that i have already documented
and explained would be catastrophic failures, and had cooperated
and helped with Part, Cat, Repl etc.

if you would like to rectify that you can help implement the
__Slice__ override.



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

it results in a massive duplication and msintenance burden.  please
read the RFC, i documented clearly why what you advocate would be
disastrous in multiple ways.

last section:

https://libre-soc.org/3d_gpu/architecture/dynamic_simd/


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

SIMT i keep telling you is the wrong word to use.  you mean SIMD

> version of nmigen
> Shape/Signal/Value/etc.,

jacob: please listen to what i am telling you.  what you envisage is EXACTLY
what is being designed.

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

yes.  that is what lane_shapes is for.

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

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

i know, it's brilliant.

i meant, the more recent ones.  Assign, Cat, Repl, and the other (older) ones
__eq__ etc.

did you see that there are unit tests which show that scalar-vector interaction
pass and function perfectly?

Signal.like() i haven't got round to doing a unit test yet, i expect it to
work 100% because UserValue is designed specifically to allow exactly that,
through the Uservalue.lower() function.

i know exactly what the requirements are having been working on this for
over 18 months and if i am honest i am getting quite annoyed that you
keep telling me "what you have designed is a failure and clearly can't work"
rather than taking the time to understand *how* it works, when i keep
telling you it does, in fact, actually work.

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