[libre-riscv-dev] [isa-dev] Re: SV / RVV, marking a register as VL.

[lkcl]

Rats.

I tried applying the new multi-SVP idea to DAXPY and strcpy, two canonical algorithms. Neither really works.

The reason is because:

1. unlike SVP where the prefixing context is applied immediately at the instruction, the two opcodes which primarily define the vector operands do *not* occir in succession (a flawed design prerequisite of this idea).

2. unlike VBLOCK, with the registers being explicitly named (despite the overhead of doing so) there can be some lookahead (static compiler analysis) in a batch of instructions.

Solutions include allowing register number context to be picked up from the 1st instruction, whilst for the 2nd the register numbers are explicitly spelled out, just like in VBLOCK.

This kinda defeats the purpose of the exercise!

Another possible solution is - was - to use some of the spare bits to specify the instruction in the VBLOCK from which the context will get its register numbers.

Whilst on the face of it this seems like a  great idea, what it means in practice is that the instruction issue phase actually has to request those instructions (almost certainly requiring a new cache line miss), and decode them, before the first one in the VBLOCK may be executed.

At least with the current VBLOCK system execution may be done (tead) in a sequential order.

If there are no ideas anyone can think of on how to fix this I this VBLOCK-SVPrefix idea goes in the "retire" bin.

Not least because SVPrefix has no way to specify zeroing, inversion or fail-on-first data dependent predication, on which the canonical strcpy example critically relies (ffirst and inv, at least).

Which is a pity as I love the idea of reducing overhead, it just needs too much advance context to work.

Anyone any ideas or solutions?

L.