[Libre-soc-dev] [RFC] SVP64 on branch instructions

[Richard Wilbur]

> On Aug 8, 2021, at 06:32, lkcl <luke.leighton at gmail.com> wrote:
> 
> i've started on the 24 bit RM decoder for BC, combining bits into 2 bit enums with only 3 entries in most cases, quite annoying that, but it is what it is.

Indeed, realizing that it is not as densely packed as if all the possibilities were used can be vexing, but it leaves room to accommodate one more option if we realize later that something could be an immense improvement with an additional mode.

[…]

> i nearly made the mistake of making Branch Conditional dependent on SVSTATE.VerticalFirst Mode, which would have serious adverse consequences for multi-issue decoding.
> 
> this is exactly the same reason why i said "Hard No" to the idea of making the decoder critically dependent on when SVSTATE.VL==0
> 
> if we were designing something that was specifically intended for non-supercomputer non-multi-issue uses, adding critical dependencies between SVSTATE and the decoder would be perfectly fine.

So I’m envisioning the supercomputer multi-issue decoder loading something like a cache line at a time from memory/cache, starting the decode by determining instruction boundaries (left-to-right cascade, but pretty quick/simple to determine 32-bit or 64-bit), then parallel decode can start on each instruction up to dispatch when hazards from interactions with resources modified by previous instructions need to be taken into account.

It is a very cool picture—even cooler because, to the extent they are used, the horizontal and vertical loop/vector modes will relieve a large amount of instruction cache and decoder activity!

I suppose dispatch will need to depend on/have a hazard on-SVSTATE (at least VL?) in order to possibly parallelize some vector operations in an implementation-dependent fashion?  It seems likely that if VL <= the number of ALU’s that the initial multiplications of a vector dot product could be dispatched in parallel.