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

[lkcl]

On October 22, 2021 12:00:48 AM UTC, Jacob Lifshay <programmerjake at gmail.com> wrote:
>I'm planning on implementing Slice next, but, a prerequisite to that is
>improving the PartType and layout APIs to get them into a shape where I
>can
>use them effectively.

... ahh let's go over this.

>Slice's result requires layouts with padding: a[3:5]

why?

PartitionedCat and PartitionedRepl did not need padding, so why would PartitionedSlice need it? (i am asking for myself just as much as anything).

i do expect PartitionedSlice to be slightly more involved, and if it is, then it is critically important to create a wiki page demonstrating the necessity of a given approach.

we did this for all the other subclasses, and they act as "understanding as well as documentation".

it would be anomalous not to do the same thing here.

now, when that gets created, it *might* turn out that it is possible to create a (very special) adapter which, given one PartType and mask, actually creates another one specially for Slice that takes a source mask and creates the PartitionPoints with appropriate padding, where it doesn't care what the (source) PartType is, because the SlicedPartType adapts under all circumstances.

but i am running ahead here: this may or may not be achievable, may have unintended ramifications that need thinking through.

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.


>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
* raise a bugreport about it and link it to the
   doc budget

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