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

no!

jacob: i *already have* SimdSignal Assign functional and correctly
working.

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:

https://git.libre-soc.org/?p=ieee754fpu.git;a=blob;f=src/ieee754/part_ass/assign.py;h=2a79cbbc596b65ea893b02cbeb79127811326bc5;hb=4fca5d99b872bf14c61d2e73932c9bf340cfd22d#l61

that's all it takes.

it's even documented

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


> > 
> > 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
implemented Signal.eq.

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.

already handled.

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

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

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.