[Libre-soc-dev] SimdSignal library

[Luke Kenneth Casson Leighton]

---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68

On Thu, Sep 30, 2021 at 7:21 PM Jacob Lifshay <programmerjake at gmail.com> wrote:

> no, it hasn't, actually. the existing PartitionedSignal stuff only supports
> lane sizes that don't need padding:

then this should have been raised and discussed!

it should have been discussed *how* to add it and *whether it was necessary*!

> yeah, well I'm saying I strongly disagree with the path you've chosen, of
> forking nmigen,

this is not my choice: it is whitequark forcing the decision by reneging on
an agreement to look at advanced extension capabilities.

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

no... it... really... isn't.

i am actually having difficulty understanding why people do not understand this.

> into using the exact same Module.If/Switch -- for the sake of
> code clarity I think they should explicitly be separated out.

they're *already* separated out - in nmigen.  i've termed them
* "Type I" low-level nmigen language constructs (ast)
* "Type 2" higher-level nmigen language constructs (dsl.Module)

in the existing nmigen design Type 2 is almost 95% entirely abstracted from
Type I, allowing Liskov Substitution Principle for 95% of operations.

there is four percent code code which does not understand or allow
Type 2 nmigen constructs to cleanly use Type I constructs.

i have fixed this.

there is under *one* percent of code in nmigen dsl.Module which assumes that
booleans are "length 1".

i have fixed that as well

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

and you didn't ask or discuss it, you went ahead.

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

no: you said, "i'm going to do X", and did not respond when i pointed
out that it would not be a good idea to ABANDON existing work
without first completing it

https://bugs.libre-soc.org/show_bug.cgi?id=708#c4


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

*then this should have been discussed and evaluated before going ahead*

and a plan discussed as to how much effort it would take to adapt the
EXISTING design - once the EXISTING design had been COMPLETED.


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

there's no chance that that's accurate.  it's taken me a day to do
Cat, and another day to do Assign.

can you please break it down by the list of operators - all of them - and give
estimates based on a per-operator, per-function, per-unit test basis.

a *full* list of *all* unit tests planned to be written.

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

you are drastically underestimating what is involved.  it took *at least*
three weeks to do the existing Formal Correctness Proofs, and there
are at least two more weeks worth to complete.

please make a *full* list of each and every Formal Correctness Proof
needed, for each arithmetic function.

> > * where the funding is coming from.
> >
> we can use the If/Switch budget?

then what budget is used to complete the if/Switch work?

l.