[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 #88 from Jacob Lifshay <programmerjake at gmail.com> ---
(In reply to Luke Kenneth Casson Leighton from comment #86)
> (In reply to Jacob Lifshay from comment #83)
> > yup, because I *wanted* lanes to be 5, 6, 12, and 24 bits wide, not 5, 6, 6,
> > and 6. That was to demonstrate how the part width is calculated to fit the
> > minimum required bits, which can be less than a lane's width, because that
> > lane occupies multiple parts.
> 
> ok.  so now we come back to comment #75, that by defining widths in terms
> of "lanes" is the wrong thing to do.
> 
> what you are calling "lane" is "part_count" times "element width".

no, I'm explicitly not. I explicitly stated the definition of "lane" i'm using
is a vector element. a part is not an element, it is a fixed number of bits
(doesn't change with different elwid). a vector element + it's padding is made
of a power of two number of parts, that number of parts is "part_count".
> 
> what is *actually needed* is just, "element width".

yes, exactly (once you add in padding). I've been saying that the whole time. 
> 
> this is because when converting Scalar code to SIMD, it is necessary
> to allow a Signal of width e.g. 16 to be multiplied by the number
> of partitions *automatically* when that Signal class is contextually-replaced
> with SimdSignal class (via a compile-time switch).
> 
> if you force people to put what you call a "lane" width in,
> that Signal width of 16 will become subdivided by 2 for elwidth=32,
> subdivided by 4 for elwidth=16 and subdivided by 8 for elwidth=8
> 
> how can you fit a 16-bit computation into 2-bit data when elwidth=8?
> 
> you can't, can you?

Of course you can't if you *insist* on the SimdSignal constructor taking the
full-simd-width. It works great, by contrast, if the SimdSignal constructor
takes the *element width*, as I've been advocating for for a while.

> this is the desired behaviour
> 
> elwidth times partition count is not.
> 
> is this clear, now?

Yup totally!

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