[Libre-soc-dev] SimdSignal library

Luke Kenneth Casson Leighton lkcl at lkcl.net
Thu Sep 30 12:38:24 BST 2021


---
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.  why would we want to duplicate that effort
when we are under time pressure and have no available financial resources
to cover it?

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

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

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

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

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?

i have 18+ months know-how with the existing implementation which
is 90% complete, and none with the new one which is about 5% of
the way towards being complete and useful.

based on what you have done please can you provide time estimates
to complete:

* unit tests
* formal correctness proofs
* where the funding is coming from.

l.



More information about the Libre-soc-dev mailing list