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

Krste Asanovic

I'm OK with going with #3 - it provides most flexibility to deal with
in future, even if we just go with illegal instruction exception, and
avoids adding tests to the compatibility suite.


On Mon, 15 Nov 2021 14:31:45 -0800, Andrew Waterman <andrew@...> said:
| 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.

|       Bill

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

| Krste


Join { to automatically receive all group messages.