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

bugzilla-daemon at libre-soc.org bugzilla-daemon at libre-soc.org
Mon Jan 1 17:29:58 GMT 2024


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

--- Comment #32 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Jacob Lifshay from comment #28)
> (In reply to Luke Kenneth Casson Leighton from comment #26)
> > the consequences are too damaging on the hardware, making it impractical.
> 
> I have read what you wrote and I disagree.

you can disagree all you like on ths one: it's not happening.
any *other* way is perfectly fine, but adding GPR dependencies
to REMAP SVSTATE/SVSHAPE is an absolute inviolate hard NO and
that is the end of the discussion, no matter how much you
disagree, or do not like it, or how much it degrades "performance".

a separate instruction that carries out the job of computing
the contents of SVSHAPE, such that it can be moved in with mtspr?

not a problem at all.

changing of sv* REMAP instructions to add a GPR as a Hazard?
get it and accept it: the answer is NO.



> if we choose to have a dynamic svshape instruction, it shouldn't affect
> precise interrupt guarantees, 

it destroys implementability by creating critical linkage between
GPRs at Decode and Issue.

it

is

not

going

to

happen.

get this through your head, STOP ARGUING, and start questioning WHY
until you do actually understand why, ok?


> the hard part is the SV loop afterwards, which will have precise interrupts
> regardless of if the svshape registers are set from a svshape instruction's
> immediates, from a dynamic svshape instruction, or from a mtspr.

and dozens of other instructions with outstanding GPR Hazards.

if there was a separate register file for Indices this would
not be a problem.  transfer from GPRs to "REMAP-Indices-regfile"
would be a single 1-in 1-out instruction.

we have been through this already with the CR regfile and with
the GPR-FPR instructions.

GPR-FPR instructions are *very deliberately* only 1-in 1-out as
anything else is catastrophic for the size of the Hazard Matrices.

> the current algorithm:
> https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=openpower/isa/
> simplev.mdwn;h=33a02e6612065f290d840e15a596dfc2177de5e5;
> hb=fa603a1e9f2259d86acf4e9451937a000d099289#l309

ok let me take a look, try to understand what is going on.

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


More information about the Libre-SOC-ISA mailing list