[Libre-soc-dev] my current plan regarding simdsignal

[Jacob Lifshay]

On Thu, Oct 21, 2021 at 6:03 PM lkcl <luke.leighton at gmail.com> wrote:
> the concept of cascading changing PartitionPoints
> (but that all react to the same elwidth or other spec) is making me pause as it wasn't part of the original planning.

Well, that was always my plan once I started describing how fixed-size
elements were needed several weeks ago. That's part of why I kept
pushing for having a class (SimdMode) that holds elwid and
vec_el_counts (or whatever equivalents we were discussing at the time)
that is explicitly *separate* from SimdLayout and SimdSignal.

> >Planned incremental PartType improvements:
> >move elwid/mask to separate class (called SimdMode) (one instance is
> >shared
> >among all SimdSignals in an ALU), separated from an individual
> >SimdSignal's
> >layout. Add member for vec_el_counts.
>
> hangonhang on, this is getting far too far ahead to be comfortable, bear in mind this is an absolutely essential design on which literally the entire project depends.
>
> this is much too big a list of changes to be done without extremely careful planning.
>
> can you first:
>
> * do a wiki page which demonstrates and descrbes the problem
>   (outline why partition padding is needed)
>   use one of the existing ones as a template,
>   shift, logicops, cat, you'll get the idea

Done, though I forgot to use the other ones as a template...

> * raise a bugreport about it
done: https://bugs.libre-soc.org/show_bug.cgi?id=733
> and link it to the
>    doc budget

Couldn't figure out which bug you meant, so I'll leave that part to you.
>
> this will give me time to think (overnight) what the implications are, and if there are any non-disruptive incremental approaches, see if you can come up with some as well (note them in the wiki page) and we can compare notes tomorrow, ok? (2am here now)

Ok, while you're thinking, I'll add the SimdMode class, but won't
modify the existing code yet.

Jacob