[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