Re: RISC-V Vector Extension post-public review updates
| We do have a choice of:On Mon, 15 Nov 2021 13:29:58 -0800, Guy Lemieux <guy.lemieux@...> said:
| 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
| 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).
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
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