[Libre-soc-isa] [Bug 1071] add parallel prefix sum remap mode

bugzilla-daemon at libre-soc.org bugzilla-daemon at libre-soc.org
Mon May 1 18:30:30 BST 2023


https://bugs.libre-soc.org/show_bug.cgi?id=1071

--- Comment #24 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Jacob Lifshay from comment #23)
> (In reply to Luke Kenneth Casson Leighton from comment #22)
> > (In reply to Jacob Lifshay from comment #16)

> > this will fail on the next iteration unless preceded by a
> > setvl MAXVL=n instruction.
> 
> yup, that's the idea -- run setvl first -- hence why I was initially
> thinking it would only read from VL and not a GPR. maybe just reserve one
> uncommon SVxd 8mmediate (59?) to mean to instead read SVxd from VL? 

maaybeee... although realistically this is an entirely new instruction
so in theory could do anything.

> that way you don't need 2x the encoding space.

irony: 64-bit instruction encodings (for e.g. svshape) are just as
long as 2 32-bit instructions. sigh.

> though i also just now thought of a way around needing setvl -- have 2 MAXVL
> fields or SPRs, tentatively named OP_MAXVL (used as a limit on
> element/subvector operations) and REG_MAXVL (used as a backup for OP_MAXVL
> and for whenever doing register offsetting like RS=RT+MAXVL, 

DCT and FFT rely on RS=RT+MAXVL being separate

> since there we
> care about register counts not how many operations our random svshape needs)
> both set by setvl when setting MAXVL, but svshape and friends only set
> OP_MAXVL, computing it from REG_MAXVL or the immediates. it may be also
> useful to likewise split VL into two, but not as necessary.

very reluctant to go to a 2nd SPR for SV state. especially right now.

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


More information about the Libre-SOC-ISA mailing list