[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 #60 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Jacob Lifshay from comment #58)
> (In reply to Luke Kenneth Casson Leighton from comment #56)
> > i am still mulling over how and whether Par...^W SimdSignal
> > can be adapted to support elwidths but also as a default
> > option create full power-2 partitions and cover all
> > permutations currently covered by PartitionedSignal.
> 
> oh, well all permutations currently covered by PartitionedSignal (at least
> add/sub/logic-ops) are waay more than just the aligned, power-of-2 lanes.

yes, i know.  that's covered in
https://libre-soc.org/3d_gpu/architecture/dynamic_simd/shape/

and it is covered by the enhancements to the layout() adapter function
i describe in comment #53.

the example in the (new) wiki page is a cleanup of the example in comment #2

there are actually NINE (nine!) underlying partition points created by
that innocuous-looking example.

so it looks like we need a completely insane 2^9 (512) permutations, right?

wrong.

there are only three in that example.

* elwidth=32
* elwidth=16
* elwidth=8

and that's where the adapter comes into play.  it defines what the switch
is, it defines the cases.

you DO NOT need a switch taking a 9-bit input

you DO NOT need a massive batch of 512 case statements

i wrote an adapter which covers the existing PartitionedSignal behaviour:
please take a look at the patches 
from comment #56 to understand it.

the "Elwdith" adapter is conceptually finished as well, based on the
code in comment #53.


> This may take a little more work to decode, and be more wires for
> part_starts, but it covers everything that both the simd_signal code I wrote
> and the layout() in comment #20 can do. it covers everything PartitionPoints
> can do, too,

jacooob: we're *not* throwing away code, we're *adapting* and slowly morphing
*existing* code, one incremental step at a time.

this is the project's base-line operating protocol

this means that we go from one known-tested to another known-tested
without scaring ourselves by taking on too much.

it does mean however that you need to have a full working knowledge of
the *existing* design.


> though we'll probably still want to restrict lanes to be
> aligned,

the Elwidth adapter from comment #53 is predicated on the fundamental
assumption that all elements start on power-two boundaries, yes.

> simd_signal.SimdPartMode.is_valid can be adapted to create a circuit used to
> feed into an Assume to get only valid part_starts combinations (checks that
> lanes are sized correctly, and are aligned correctly).

you're confusing me with a new design when my entire mindset is focussed
on the existing design.

if you describe things to me in terms of how the EXISTING design is
code-morphed *INTO* the proposed new design - not replaced by - CHANGED INTO -
i will be able to understand.

feet on the ground, jacob.

rename is done, btw.

commit df93b8f37bea53917d67e87ce2190981bc2ef667 (HEAD -> master, origin/master)
Author: Luke Kenneth Casson Leighton <lkcl at lkcl.net>
Date:   Sun Oct 10 11:35:20 2021 +0100

    big rename PartitionedSignal to SimdSignal (shorter)

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