3 ms·

The 32 variable length registers don’t overlap; the register grouping is orthogonal to the length of each register. The grouping... sounds “interesting” to imp

The 32 variable length registers don’t overlap; the register grouping is orthogonal to the length of each register. The grouping... sounds “interesting” to implement in an OoOE design. Most obvious would be to have the instruction decoder emit one uop per register in the grouping... but that means vsetvli would have to stall decoding until it’s resolved. But that also seems to be how element size is set, so that would kill the performance of mixing precision in the same kernel... Well I guess it could assume the grouping doesn’t change and flush the pipeline if it did. But you still don’t want to be mixing kernels with different groupings...

brucehoult 6y ago
It's absolutely essential to be able to change vsetvli in the middle of a kernel. It is expected that in a future expanded Vector instruction set with 48 bit or 64 bit opcodes the vtype will be explicitly encoded in every instruction and can change every instruction. Right now the vsetvli is setting (slightly) persistent state that affects following instructions. You're allowed to put one before every vector instruction if you want, without significant execution penalty -- there will be a little, from extra instruction fetch and decode -- but similar to doing, say, an integer add between each vector instruction. The natural implementation even now is to have each vector instruction pick up the current vtype when it is decoded and carry it along with it through the pipeline as a few extra bits of opcode. You certainly don't want to have any stalls or pipeline flushes just because the vtype changes.