[Libre-soc-dev] Triangular REMAP schedule

[lkcl]

On Tue, May 31, 2022 at 5:27 AM Jacob Lifshay <programmerjake at gmail.com> wrote:

> just a pure triangle schedule isn't sufficient for Knuth's Algorithm D,
> since it has the conditionally-executed fix-up loop.
>
> Knuth's Algorithm M imho isn't a good justification for a triangle
> schedule since once you get past around 5 words you should be
> using Karatsuba multiplication (or more complex algorithms) instead...
> it's faster. 5 words is short enough that just having the outer loop
> be fully unrolled is sufficient...it'd be like 10-15 instructions for the
> whole outer loop.

>>
>>
>> it would be a fascinating application of SVP64 in that for the first time some of SVSTATE would need to be context-switched, i.e. the computation of a partial intermediary result within an outer loop would roll SVSTATE forward, and would need rolling back before calculating the next stage.
>
>
> imho that just too complex....

it's a complex conceptual / software problem not a complex hardware
problem, at all.  fairly close to the brain-melting threshold, i have to
admit.

>> this should be dead easy to calculate these kinds of offsets: i would like to make it more general, and include simple triangular mapping so as not to have to add conflictd.
>
>
> conflictd is still necessary...

i'll answer this separately (separate thread). the background behind
why conflictd exists at all is itself quite involved.

l.