[Libre-soc-dev] SimdSignal library

[Jacob Lifshay]

On Thu, Sep 30, 2021, 04:38 Luke Kenneth Casson Leighton <lkcl at lkcl.net>
wrote:

> ---
> crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
>
> On Thu, Sep 30, 2021 at 9:21 AM Jacob Lifshay <programmerjake at gmail.com>
> wrote:
> >
> > I decided that I think it is still a better idea to have a
> > PartitionedSignal equivalent that supports arbitrary lane sizes, even
> > if they need padding.
>
> this has already been done.


no, it hasn't, actually. the existing PartitionedSignal stuff only supports
lane sizes that don't need padding:
so, both SimdValue and PartitionedSignal can support types that partition
like so, since no padding is required (1-character per bit):
     24v     16v       8       0
[--u8--][--u8--][--u8--][--u8--]
[-----u16------][--u8--][--u8--]
[--u8--][--u8--][-----u16------]
[-----u16------][-----u16------]
[-------------u32--------------]

However, only SimdValue supports types that need padding, such as the
following type where the lane type is always u8 no matter how partitioned:
padding is denoted with p:
     24v     16v       8       0
[--u8--][--u8--][--u8--][--u8--] u8,u8,u8,u8
[ppppppp---u8--][--u8--][--u8--] u8,u8,u8
[--u8--][--u8--][ppppppp---u8--] u8,u8,u8
[ppppppp---u8--][ppppppp---u8--] u8,u8
[ppppppppppppppppppppppp---u8--] u8

Another example that only SimdValue supports:
extracted biased exponent fields for 16, 32, and 64-bit floats, which have
5, 8, and 10 bits respectively:
  15v  10v    5    0
[-u5][-u5][-u5][-u5] f16,f16,f16,f16
[p---u8--][-u5][-u5] f32,f16,f16
[-u5][-u5][p---u8--] f16,f16,f32
[p---u8--][p---u8--] f32,f32
[ppppppppp---u10---] f64


  why would we want to duplicate that effort
> when we are under time pressure and have no available financial resources
> to cover it?
>

because it isn't duplicate effort

>
> and, xor, or obviously don't partition, they are bit-wise:
>
> https://git.libre-soc.org/?p=ieee754fpu.git;a=blob;f=src/ieee754/part/partsig.py;h=032749cf45b0b39256b02d703f2b6a7a1b52c324;hb=58c9fe6d719842132dd18fc6264ee525f1fc7f88#l131
>
> add, shift, sub, these all use PartitionedAdder that you wrote 2+ years
> ago:
>
> https://git.libre-soc.org/?p=ieee754fpu.git;a=blob;f=src/ieee754/part/partsig.py;h=032749cf45b0b39256b02d703f2b6a7a1b52c324;hb=58c9fe6d719842132dd18fc6264ee525f1fc7f88#l221


yup, and those can all be adapted to work with SimdValue.

>
>
> __eq__, __ge__, __le__ etc were written 18 months ago:
>
> https://git.libre-soc.org/?p=ieee754fpu.git;a=blob;f=src/ieee754/part/partsig.py;h=032749cf45b0b39256b02d703f2b6a7a1b52c324;hb=58c9fe6d719842132dd18fc6264ee525f1fc7f88#l293
>
>
>
>
> > I also think that trying to force Simd-ness apon
> > nmigen's Module, If, Cat, Mux, Switch, and Value is not a good idea
> > primarily because of confusion, and also because creating a hard fork
> > of nmigen is not a good idea.
>
> this is being resolved.
>

yeah, well I'm saying I strongly disagree with the path you've chosen, of
forking nmigen, but even forking nmigen doesn't matter to me as much as
your choice to try and force PartitionedSignal, with it's clearly different
semantics, into using the exact same Module.If/Switch -- for the sake of
code clarity I think they should explicitly be separated out.

>
> > Therefore, I ended up creating a
> > proof-of-concept SimdSignal library that is all laid out with the API
> > I think is best:
> >
> > https://salsa.debian.org/Kazan-team/simd_signal/-/tree/master
>
> whiy is it on an unmanaged unauthorised server outside of Libre-SOC
> control?
>

because I (still) don't have the required access to create new repos on
git.libre-soc.org. Also, Kazan-team is effectively controlled by Libre-soc,
just as much as github.com/nmigen is controlled by nmigen's team.

>
> > I got a little carried away with the implementation, I had been
> > planning on working on it a day or two before posting on the mailing
> > list rather than a week...oops.
>
> why are you working on this when there is no budget for it, rather than
> helping to complete an existing implementation which _does_ have
> budget and has been 90% completed?
>
> it looks like it's fantastic work - why did you go ahead with it without
> discussion?
>

i did discuss...a week ago:
https://bugs.libre-soc.org/show_bug.cgi?id=708

>
> why did you do this instead of helping with the existing code?
>
> why did you not respond to my message on the bugtracker explaining
> that due to time and budget constraints it would be better to work
> *together* to complete the *existing* design then *afterwards* look
> at alternative implementations in a review pass?
>

sorry. I do think supporting sizes that need padding will be critical
enough that it's worth working on now, additionally I already created
helper classes (SimdValueLanewise) that make it trivial to support
operations that are too complicated to try to do more efficiently than just
extracting every possible lane, doing the operation as scalar nmigen
operations, then merging them all back into a full SimdValue -- that's what
I did for SimdCat:
https://salsa.debian.org/Kazan-team/simd_signal/-/blob/b80818404a824c3b3e152a6a55dc9ba87fbbec2e/src/simd_signal.py#L1316
the core of the implementation of SimdCat is just:
def _get_lane_value(self, lane: SimdLane) -> _ValueCastableType:
        return nmigen.Cat(i.lane(lane) for i in self.inputs)

based on what you have done please can you provide time estimates
> to complete:
>
> * unit tests
>
2 weeks

> * formal correctness proofs
>
2 weeks -- we can build a helper function that extracts each possible lane
and does the operation on the lanes, then merges them back
together...allowing writing reference implementations to be pretty trivial
to write. I could probably do all the arithmetic/slicing/mux/cat/repl/etc.
functions in 1-2 days once the helper is written since it's mostly
copy-paste and relying on nmigen and that helper function to do all the
hard work.

> * where the funding is coming from.
>
we can use the If/Switch budget? Part of implementing SimdModule will be
implementing If/Switch anyway (already about 30% done).

Jacob