[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 #31 from Jacob Lifshay <programmerjake at gmail.com> ---
(In reply to Luke Kenneth Casson Leighton from comment #27)
> (In reply to Jacob Lifshay from comment #23)
> 
> > why go through all that when you can just derive the signal width from the
> > lane shapes -- avoiding wasting extra bits or running out of bits, as well
> > as avoiding the need to manually specify size? Having the size be computed
> > doesn't really cause problems imho...
> 
> because the idea is to do a literal global/search/replace "Signal"
> with "PartitionedSignal" right throughout the entirety of the ALU
> codebase.
> 
> and the input argument on all current-Signals is not an elwidth, 
> it's an "overall width".

I'm 99% sure you're mis-identifying that...the input argument for all current
Signals *is* the bit-width of the current lane (aka. elwidth or XLEN) except
that our code currently is specialized for the specific case of elwidth=64.
This is exactly how all SIMT works (which is exactly what we're trying to do
with transparent vectorization). The types and sizes are the type/size of a
*single* lane, not all-lanes-mushed-together.
> 
> (actually, have a PSpec which dynamically determines at run/compile
> time *which* class to use: Signal or PartitionedSignal).

That's just like how SIMT programs can be run un-vectorized.
> 
> when i said "there will be NO fundamental changing of the ALU code"
> i REALLY meant it.

which is why we need to go all-in on SIMT, since that is the *one vectorization
paradigm* that requires minimal modifications to our ALU code.

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