[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 #112 from Jacob Lifshay <programmerjake at gmail.com> ---
(In reply to Jacob Lifshay from comment #111)
> (In reply to Luke Kenneth Casson Leighton from comment #109)
> > (In reply to Jacob Lifshay from comment #108)
> >   but when added in "fixed" mode it should add five to the
> >   *whole* length then recompute the Vector Lane widths
> >   using the partition counts.  obviously here if the
> >   programmer fails to take into account the partition
> >   allocation some of the computed Vector Element widths
> >   will not fit (XLEN=64 +3 will be 67 which is not
> >   divisible by 8) but that is their problem to sort out
> 
> I'd argue strongly that we should specifically not do that, what we should
> do instead is mirror how XLEN works in the OpenPower spec pseudo-code, where
> XLEN + 5 means that each per-vector-element instance ends up with types 5
> bits wider, so:
> 
> elwid=8: XLEN + 5 -> element width of 8 + 5 == 13
> elwid=16: XLEN + 5 -> element width of 16 + 5 == 21
> elwid=32: XLEN + 5 -> element width of 32 + 5 == 37
> elwid=64: XLEN + 5 -> element width of 64 + 5 == 69
> 
> The above is the semantics I explicitly rely on in the pseudo-code for
> addg6s (where it creates values with a width of XLEN + 4, because it needs 4
> extra bits to prevent the logic from overflowing), we should not make
> SimdSignal's XLEN behave differently just because you like doing arithmetic
> on the full SIMD width.

After thinking a bit, the actual issue is that element-widths are the thing
arithmetic needs to happen on -- 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.

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