[Libre-soc-bugs] [Bug 713] PartitionedSignal enhancement to add partition-context-aware lengths
bugzilla-daemon at libre-soc.org
bugzilla-daemon at libre-soc.org
Tue Oct 12 20:19:27 BST 2021
--- Comment #85 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Jacob Lifshay from comment #82)
> well, the problem is that, to correctly maintain the appearance of operating
> on *scalar* values needed for all our existing OpenPower ALUs (waay more
> code than PartitionedSignal), we need it to look like a single element,
> *not* a list. This means SimdSignal.width *has to be* the width of a
> *single* element.
jacob: i *already have* SimdSignal Assign functional and correctly
note, i did not say "eq" i said "Signal.like" and talked about casting.
that's completely different.
to move the topic to SimdSignal.eq:
* SimdSignal.eq *already detects* the type of object that it is
being Assigned to.
* for a SimdSignal.eq(Signal) it performs a scalar-to-vector
elwidth-context-aware duplication (Vector ISA "broadcast").
* for a SimdSignal.eq(SimdSignal) it performs a full range of detection
of partition sizes (smaller, equal, greater) and deals with them.
*this is already done*.
*it is functional*
you are weeks if not months behind on the functionality of the design
which *already works*
here is the revelant code:
that's all it takes.
it's even documented
> > 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.
> we need Signal/SimdSignal interconversion, but it should be done via having
> non-SIMD code access SimdSignal.sig, or by a .bitcast member function, not
> by just doing Signal.eq.
i did the analysis 2 weeks ago and successfully worked it out and successfully
there is no need and absolutely no desire to complicate things that have
already been successfully done and completed.
> In particular, what your advocating for (for
> SimdSignal to transparently inter-convert with Signal),
for *casting* - yes. when the developer *asks* for that, by using
Signal.like and uses casting.... yes.
> just 1:1 copying
> bits, will *not work* nicely -- it's in conflict with what happens when a
> scalar is converted to a vector, which is that that scalar is *splatted*
> into all lanes of the vector, not that the scalar is split into pieces and
> each piece becomes a lane.
> 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. whitequark,
just before banning me from participation on #nmigen, 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
> 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.*
it *works* - full stop. there is not one single unit test in the entirety
of test_partsig.py which is not already demonstrating and proving that this
concept - fact - works - fact.
please listen to what i am telling you: it works! fact!
have you run the unit test and / or contributed to the individual modules?
You are receiving this mail because:
You are on the CC list for the bug.
More information about the libre-soc-bugs