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


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.

But I'm OK with #1 or #3.

I'd personally prefer #3 due to laziness, but I don't have a technical objection to #1.


-----Original Message-----
From: tech-vector-ext@... <tech-vector-ext@...> On Behalf Of Krste Asanovic
Sent: Monday, November 15, 2021 4:58 PM
To: Guy Lemieux <guy.lemieux@...>
Cc: Krste Asanovic <krste@...>; tech-vector-ext@...
Subject: Re: [RISC-V] [tech-vector-ext] RISC-V Vector Extension post-public review updates


>>>>> 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.


Join { to automatically receive all group messages.