[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 #121 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
context: this is starting to get complicated so i am moving the discussion
back to the bugtracker

http://lists.libre-soc.org/pipermail/libre-soc-dev/2021-October/003972.html

i just put in some unused code (in advance of setting up the examples
in the URL https://libre-soc.org/3d_gpu/architecture/dynamic_simd/shape/

https://git.libre-soc.org/?p=ieee754fpu.git;a=commitdiff;h=417f7f93bf3baf576e537cde32f118b2a50eab46

it's over 50% comments because it's... complicated (dual mathematics rules,
PRIORITY_FIXED, PRIORITY_ELWID).

basically: when both LHS and RHS are PRIORITY_FIXED (both had a lane_shapes
of None), then it should be obvious that the "Correct Thing To Do" is just
to multiply the two fixed_widths together and create a SimdShape out of
that.

why?

because *both* LHS and RHS were established (created) with the requirement
that "elwidths shall be auto-computed to fill the entirety of the partition,
as determined by overall width and the vec_el_counts,
regardless of what elwid is set to.

on the other hand, when *either* LHS or RHS have had an elwidths argument
given, it is the elwidths that have to be preserved (multiplied)
individually:

    result.lane_shapes[0] = LHS.lane_shapes[0] * RHS.lane_shapes[0]
    result.lane_shapes[1] = LHS.lane_shapes[1] * RHS.lane_shapes[1]
    ...
    ...

the only case i'm not sure about is PRIORITY-BOTH, there.  i don't
believe it's safe for the return result to be PRIORITY-BOTH, because
you could have LHS[0] = 1000, RHS[0] = 1, and LHS[1] = 1, RHS[1] = 999,
and a fixed_width doesn't work out, there.

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