Re: RISC-V Vector Extension post-public review updates
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.
Krste
| 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
| 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
|
in future, even if we just go with illegal instruction exception, and
avoids adding tests to the compatibility suite.
Krste
| On Mon, Nov 15, 2021 at 2:17 PM Bill Huffman <huffman@...> wrote:On Mon, 15 Nov 2021 14:31:45 -0800, Andrew Waterman <andrew@...> said:
| 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
| 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
|