From: Andrew Waterman <andrew@...>
Sent: Monday, November 15, 2021 5:32 PM
To: Bill Huffman <huffman@...>
Cc: Krste Asanovic <krste@...>; Guy Lemieux <guy.lemieux@...>; tech-vector-ext@...
Subject: Re: [RISC-V] [tech-vector-ext] RISC-V Vector Extension post-public review updates

 

EXTERNAL MAIL

 

 

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.

 

Other nooks and crannies are also dependent on vtype.  For example, widening instructions are not valid for LMUL large enough to make the wider operands cover more than 8 registers.

 

      Bill

 

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

EXTERNAL MAIL



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