On Mon, 15 Nov 2021 13:29:58 -0800, Guy Lemieux <guy.lemieux@...> said:

| We do have a choice of:

| 1) Mandate all implementations raise an illegal exception in this
| case.  This is my preferred route, as this would be a minor errata for
| existing implementations (doesn't affect software), and we would not reuse
| this state/encoding for other purposes.

| 2) Allow either correct execution or illegal exception (as with
| misaligned). 

| 3) Consider "reserved", implying implementations that support it are
| non-conforming unless we later go with 2).

| I don’t have a strong opinion, but I prefer a route that allows us to recover those instruction encodings — they seem to be getting scarce hence represent
| value. You said there were already requests for extra instructions — would this space be usef for any of them (or other as-yet-unforeeen instructions)?

| Does (3) give us the best route to reuse the encodings in the future? I’m a bit confused about the permanence of (1), and I don’t like the possibility
| software fragmentation that will arise from (2).

| Guy

The problem with this encoding space is that in some cases (i.e.,
vector indexed stores) the reserved encoding is actually only for some
combination of vtype control state + instruction bits, or in the
others it is low-quality space, e.g., where the source vector register
specifiers overlap.

So, I would assume 1) would be permanent.

As a general comment, folks seem to overweight the long-term value of
awkward corners of the encoding space, versus the short/medium-term
benefits of having clean and simple encoding. More mature
architectures tend to add cleaner extended encodings (prefix
bytes/words) rather than ramming substantial additions into awkward
unused corners.

Krste