[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 #86 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Jacob Lifshay from comment #83)
> (In reply to Luke Kenneth Casson Leighton from comment #81)
> > cpart_wid = -min(-lane_shapes[i] // c for i, c in part_counts.items())
> > 
> > that's definitely dividing the lane_shape _total_ by the part count.
> 
> that's because that's computing the width of *one* part. a single lane can
> occupy multiple parts (a lane occupies part_counts[i] parts)

i did say: it's important to stop using the word "lane" because it has
multiple definitions.

> 
> 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".

what is *actually needed* is just, "element width".

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?

therefore, so as not to make massive intrusive changes to the Scalar
code, polluting it with SIMD-style context that it doesn't need,
the *element* width has to be passed in to layout() *not*
element width times partition count.

by passing that *element* width in, layout() will allocate 16-bit
elements *of that size*, at *all* elwidths.

this is the desired behaviour

elwidth times partition count is not.

is this clear, now?

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