[Libre-soc-bugs] [Bug 713] PartitionedSignal enhancement to add partition-context-aware lengths

[bugzilla-daemon at libre-soc.org]

https://bugs.libre-soc.org/show_bug.cgi?id=713

--- Comment #116 from Jacob Lifshay <programmerjake at gmail.com> ---
(In reply to Luke Kenneth Casson Leighton from comment #113)
> (In reply to Jacob Lifshay from comment #112)
> 
> > After thinking a bit, the actual issue is that element-widths are the thing
> > arithmetic needs to happen on
> 
> yes, good, you understand now.

I've always understood that part, I've just been trying to tell you that cuz it
appeared as though you were advocating for stuff to work on the full simd width
and then calculate element widths based on that.
> 
> > -- you can come up with whatever algorithm you
> > like for deciding what full simd width to use,
> > as long as the element widths
> > take priority.
> 
> (that algorithm is: layout())
> 
> there are actually two separate and distinct cases.
> 
> 1) the add6gs example you gave (which is the same as the rwlwinm example)
> 
> 2) the times where the whole SIMD Signal is defined by the register file
>    width (64 bit fixed width)

I've been planning on register i/o signals just being set to XLEN, since that
gives a 64-bit simd signal when vec_el_counts is setup for 64-bit vectors, it
also automatically adapts for if we want a 32-bit cpu by setting vec_el_counts
to:
vec_el_counts = {
    IntElWid.I32: 1,
    IntElWid.I16: 2,
    IntElWid.I8: 4,
}

> edit: but you see now, why because the arithmetic needs to be done
> simultaneously on *all* vector element widths at *all* elwidths,
> only rudimentary arithmetic can be performed?

that's not actually the case...

> bitwise OR of 0x9 onto a simultaneous vector width of 8 and 16 makes
> absolutely no sense.

There aren't many uses, but it still makes sense for XLEN | 9:
elwid=8: 8 | 9 = 9
elwid=16: 16 | 9 = 25
elwid=32: 32 | 9 = 41
elwid=64: 64 | 9 = 73

Example use:
`some_shape | 0x7` to round it up to 1 less than a multiple of 8

Also, when implementing __add__ and friends, don't forget cases like:
XLEN + XLEN % 2

-- 
You are receiving this mail because:
You are on the CC list for the bug.