[Libre-soc-dev] sv.mv x: the instruction from hell

[Jacob Lifshay]

On Fri, Jun 3, 2022, 16:46 lkcl via Libre-soc-dev <
libre-soc-dev at lists.libre-soc.org> wrote:

> an explanation of the subject line: mv.x is the worst idea ever for scalar
> ISAs:
>
>     GPR(RT) = GPR(GPR(RA))
>
> which puts the entire regfile as both a RaW and a WaR hazard, basically
> locking up all instructions whilst this one is in progress.


there's a pretty simple fix, make the *scalar* instruction limit itself to
VL:
idx = GPR(RA)
GPR(RT) = idx < VL ? GPR(RB + idx) : 0

that way even scalar instructions have a known range of registers [RB, RB +
VL) where their input could come from.

  traditional Vector ISAs do not suffer the same fate because the indices
> are contained within one single Vector Reg.
>
> i have an idea which will avoid the hazards by completely cheating: move
> the lookup indices to a REMAP schedule.  this becomes incredibly powerful
> because the index lookups can apply to anything, not just mv.
>
>     def remap(i):
>         return GPR(i)
>
> where the normal SV loop is:
>
>     for i in range(VL):
>           GPR(RT+remap1(i)) = op(GPR(RA+remap2(i)...)
>
> by setting the rule that the Hazards are *NOT* to be observed, during the
> usage of this type of remap, all of the problems go away.
>

elaborate on what you mean by not to be observed...i don't understand what
you mean.

>
> thoughts appreciated.
>

going off what I do understand, i think it's a pretty bad idea because it
takes a slow/expensive instruction and just makes it slower and more
expensive, also you'd need an additional instruction to set the remap
nearly every time.

Jacob