Re: RISC-V Vector Extension post-public review updates

Guy Lemieux

To determine the trap cause, without such a bit, software will have to examine many possible vtype settings that are unique for each particular instruction. The trap handler will be highly customized for each cpu implementation.

This could be done more easily in a handful of logic gates, without a vastly different flow in the trap handler (which will already know to check vill).


On Mon, Nov 15, 2021 at 3:24 PM Krste Asanovic <krste@...> wrote:

On Nov 15, 2021, at 3:13 PM, Guy Lemieux <guy.lemieux@...> wrote:

On Mon, Nov 15, 2021 at 2:17 PM Bill Huffman <huffman@...> wrote:
I'm glad this came up.  I certainly wouldn't want to try to make an implementation work for these cases.  😊

I lean a bit toward #3, not so much because we might use the space as because I think we've called all the other similar corners of opcode space that don't make sense to implement "reserved."  Possibly that's because they might make sense someday and this won't.

I think these encodings are qualitatively different from other nooks and crannies, since their availability is a function of the dynamic vtype setting.  So we can rationalize the departure from the normal practice of marking the state reserved.

Ok, this makes the opcodes virtually useless for other instructions.

Instead, shouldn't we be setting a bit similar to vill?  I realize vill is only set on illegal vset* instructions; in this case it would be a new bit which is only set on executing instructions that are incompatible with the current (but otherwise valid) vtype ?


There’s no benefit to setting vill versus just taking a trap in this case.

Vill is there so we don’t have to add the first trap on a write of a particular data value, and also to provide a discovery mechanism.


Join { to automatically receive all group messages.