|
Re: RISC-V Vector Extension post-public review updates
|| 1) Mandate all implementations raise an illegal exception in thisOn Tue, 16 Nov 2021 07:36:40 -0800 (PST), "ghost" <ghost@major2nd.com> said: || 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'm assuming we're going to push to ratify 1) unless I hear strong || objections. | I agree that #1 is the least unfortunate of the alternatives, but I want to | raise a flag because I think there are larger considerations. | AFAIK, the vector extensions are unique among proposed non-privileged | extensions in their extensive functional dependency on machine state other | than the instruction. The task group had a strong consensus in retaining a 32-bit encoding for the vector extension, which led to the separate control state. The desire to stick with 32-bit encoding was not only to avoid adding a new instruction length, but also to reduce static and dynamic code size. It should be noted that fixed-instruction-width RISC vector architectures (ARM SVE2, IBM VMX) have had to adopt a prefix model to accomodate vector encodings, with similar concerns about intermediate control state (variable-length ISAs just have very long vector instruction encoding). With obvious bias, I believe the RISC-V solution is cleaner than these others in this regard. | Avoiding this kind of dependency seems to have been a | consistent and important goal (one of many, of course) in previous designs. | For example, including a rounding mode in every floating point instruction, | even the FMA group, multiplied the number of code points for these | instructions by 8, even though it is not clear (at least to me) how | important the use cases are. (IMO this might tend to support ds2horner's | proposal to use 48- or 64-bit instructions for some of the vector | capability, but that is off topic for the present discussion; and I can see | a counter-argument that using machine state simplifies pipelining setup that | might depend on that state.) A longer 64-bit encoding was always planned for the vector extension as it is clear that the set of desired instruction types could not fit in 32 bits. The main simplification from using the separate control state was in avoiding the longer instruction width, not in pipelining, which it actually complicates. | Because of this dependency, it seems to me | that the current issue creates a currently rare, and undesirable, situation | where an illegal exception trap depends on a significantly complex | interaction between an instruction and the machine state. Just something to | bear in mind for the future. In some cases, the trap is only dependent on the instruction bits (e.g., vfwadd.wv). In others, it depends on two bits of vtype plus the instruction bits. Of course, actual hardware implementations have many cases where behavior of unprivileged instructions depends on control state settings in privileged layers in much more complex ways. Krste | -- | L Peter Deutsch <ghost@major2nd.com> :: Aladdin Enterprises :: Healdsburg, CA | Was your vote really counted? http://www.verifiedvoting.org |
|
|
|
|
Re: RISC-V Vector Extension post-public review updates
ghost
1) Mandate all implementations raise an illegal exception in thisI agree that #1 is the least unfortunate of the alternatives, but I want to raise a flag because I think there are larger considerations. AFAIK, the vector extensions are unique among proposed non-privileged extensions in their extensive functional dependency on machine state other than the instruction. Avoiding this kind of dependency seems to have been a consistent and important goal (one of many, of course) in previous designs. For example, including a rounding mode in every floating point instruction, even the FMA group, multiplied the number of code points for these instructions by 8, even though it is not clear (at least to me) how important the use cases are. (IMO this might tend to support ds2horner's proposal to use 48- or 64-bit instructions for some of the vector capability, but that is off topic for the present discussion; and I can see a counter-argument that using machine state simplifies pipelining setup that might depend on that state.) Because of this dependency, it seems to me that the current issue creates a currently rare, and undesirable, situation where an illegal exception trap depends on a significantly complex interaction between an instruction and the machine state. Just something to bear in mind for the future. -- L Peter Deutsch <ghost@major2nd.com> :: Aladdin Enterprises :: Healdsburg, CA Was your vote really counted? http://www.verifiedvoting.org
|
|
|
|
Re: RISC-V Vector Extension post-public review updates
| From an ISA definition point of view it doesn't make sense to forbid properly formed operations to benefit aOn Tue, 16 Nov 2021 10:18:41 +0100, Victor Moya <victor.moya@semidynamics.com> said: | specific hardware implementation. It's an ugly hack. A common goal in ISA design is avoiding complex implementations for operations that are not used by software. | If a given hardware implementation can't handle it in an optimal way and it really doesn't have real software | use (ie, performance is irrelevant) it can just trigger a slow path (microcode sequence or trap to software | emulation). This might add the only microcode or emulation path to a design, and for an operation that is never used. | But given that it isn't the first case in the spec it isn't really much of a problem. Between making halfway | hacks, I think it's better to make it completely illegal (option #1) than to add additional fragmentation | that may affect compilers with #2 or #3. Making it reserved allows for future definition as illegal, and is a smaller deviation from the frozen spec. It does not cause fragmentation as software, and especially compilers, will not use this case. | If the vector specification is required to be optimal for a specific hardware implementation better make it | explicitly so and not go in roundabout ways.. The specification is explicit in being designed to support wide implementations that internally rearrange data, which is the class of machines that this change is aimed at. The current design evolved to remove the fragmentation that would arise from making data rearrangement visible, while also not requiring a design with explicit upper/lower or odd/even steps to handle mixed-width operations. Krste | Victor | On Mon, Nov 15, 2021 at 10:05 PM Krste Asanovic <krste@sifive.com> wrote: | Apart from requests for more instructions, which can be handled with | later extensions, there were no real substantive updates. | I did notice one issue at end of public review, however. | The current specification allows some instructions to have two vector | source operands read from the same vector register but with different | EEW. For example, a vector indexed store with the index vector and | data vector overlapping, but different EEW. Or a widening vector add | (vwadd.wv) where the two vector sources overlap but have different | EEW. This complicates implementations that internally restripe the | vector data (e.g., internal SLEN), and does not have a valid software | use (cue folks furiously trying to construct one...). | The proposal is to allow implementations to raise an illegal | instruction exception in this case. I believe this is an important | and necessary change to accomodate internal striping. In practice, | this change has no impact on software. | 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'm assuming we're going to push to ratify 1) unless I hear strong objections. | Krste |
|
|
|
|
Re: RISC-V Vector Extension post-public review updates
If a given hardware implementation can't handle it in an optimal way and it really doesn't have real software use (ie, performance is irrelevant) it can just trigger a slow path (microcode sequence or trap to software emulation). But given that it isn't the first case in the spec it isn't really much of a problem. Between making halfway hacks, I think it's better to make it completely illegal (option #1) than to add additional fragmentation that may affect compilers with #2 or #3. If the vector specification is required to be optimal for a specific hardware implementation better make it explicitly so and not go in roundabout ways.. Victor
On Mon, Nov 15, 2021 at 10:05 PM Krste Asanovic <krste@...> wrote:
|
|
|
|
Re: RISC-V Vector Extension post-public review updates
In this case, the trap cause can be determined by looking at the vtype
value and the instruction encoding (most only need to look at instruction encoding), independent of implementation. No vtype probing is needed. (assuming there isn't some non-conforming use of the encoding, which is out-of-scope for any discussion of standard trap handlers) Krste | To determine the trap cause, without such a bit, software will have to examine many possible vtype settings that are unique for each particularOn Mon, 15 Nov 2021 15:49:03 -0800, Guy Lemieux <guy.lemieux@gmail.com> said: | instruction. The trap handler will be highly customized for each cpu implementation. | This could be done more easily in a handful of logic gates, without a vastly different flow in the trap handler (which will already know to | check vill). | Guy | On Mon, Nov 15, 2021 at 3:24 PM Krste Asanovic <krste@sifive.com> wrote: | On Nov 15, 2021, at 3:13 PM, Guy Lemieux <guy.lemieux@gmail.com> wrote: | On Mon, Nov 15, 2021 at 2:17 PM Bill Huffman <huffman@cadence.com> 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. | Ok, this makes the opcodes virtually useless for other instructions. | Instead, shouldn't we be setting a bit similar to vill? I realize vill is only set on illegal vset* instructions; in this case it | would be a new bit which is only set on executing instructions that are incompatible with the current (but otherwise valid) vtype ? | Guy | There’s no benefit to setting vill versus just taking a trap in this case. | Vill is there so we don’t have to add the first trap on a write of a particular data value, and also to provide a discovery mechanism. | Krste
|
|
|
|
Re: RISC-V Vector Extension post-public review updates
Guy Lemieux
To determine the trap cause, without such a bit, software will have to examine many possible vtype settings that are unique for each particular instruction. The trap handler will be highly customized for each cpu implementation. This could be done more easily in a handful of logic gates, without a vastly different flow in the trap handler (which will already know to check vill). Guy
On Mon, Nov 15, 2021 at 3:24 PM Krste Asanovic <krste@...> wrote:
|
|
|
|
Re: RISC-V Vector Extension post-public review updates
I guess simpler examples are anytime you use v0 as mask and a data
source. These aren't useful use-cases, so existing software shouldn't have been doing this (except test code). Krste | On Mon, Nov 15, 2021 at 3:40 PM Krste Asanovic <krste@sifive.com> wrote:On Mon, 15 Nov 2021 15:45:14 -0800, Nick Knight <nick.knight@sifive.com> said: | I'm not sure if C intrinsics can generate this case, | https://godbolt.org/z/qj6WzYc76 | | but there are | other cases where dynamic value settings can result in illegal | instruction traps, so the result would be the same that | implementations will either trap or do something non-conforming. | Krste |||||| On Mon, 15 Nov 2021 15:28:25 -0800, Craig Topper <craig.topper@sifive.com> said: | | On Nov 15, 2021, at 3:24 PM, Krste Asanovic <krste@sifive.com> wrote: | | On Nov 15, 2021, at 3:13 PM, Guy Lemieux <guy.lemieux@gmail.com> wrote: | | On Mon, Nov 15, 2021 at 2:17 PM Bill Huffman <huffman@cadence.com> 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. | | Ok, this makes the opcodes virtually useless for other instructions. | | Instead, shouldn't we be setting a bit similar to vill? I realize vill is only set on illegal vset* instructions; in this case | it | | would be a new bit which is only set on executing instructions that are incompatible with the current (but otherwise valid) vtype | ? | | Guy | | There’s no benefit to setting vill versus just taking a trap in this case. | | Vill is there so we don’t have to add the first trap on a write of a particular data value, and also to provide a discovery | mechanism. | | Krste | | Is it possible to generate one of these cases from C with crazy uses of vreinterpret and vget/vset intrinsics? What should the compiler | do for | | such code? | | Craig | | |
|
|
|
|
Re: RISC-V Vector Extension post-public review updates
On Mon, Nov 15, 2021 at 3:40 PM Krste Asanovic <krste@...> wrote:
but there are
|
|
|
|
Re: RISC-V Vector Extension post-public review updates
I'm not sure if C intrinsics can generate this case, but there are
other cases where dynamic value settings can result in illegal instruction traps, so the result would be the same that implementations will either trap or do something non-conforming. Krste | On Nov 15, 2021, at 3:24 PM, Krste Asanovic <krste@sifive.com> wrote:On Mon, 15 Nov 2021 15:28:25 -0800, Craig Topper <craig.topper@sifive.com> said: | On Nov 15, 2021, at 3:13 PM, Guy Lemieux <guy.lemieux@gmail.com> wrote: | On Mon, Nov 15, 2021 at 2:17 PM Bill Huffman <huffman@cadence.com> 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. | Ok, this makes the opcodes virtually useless for other instructions. | Instead, shouldn't we be setting a bit similar to vill? I realize vill is only set on illegal vset* instructions; in this case it | would be a new bit which is only set on executing instructions that are incompatible with the current (but otherwise valid) vtype ? | Guy | There’s no benefit to setting vill versus just taking a trap in this case. | Vill is there so we don’t have to add the first trap on a write of a particular data value, and also to provide a discovery mechanism. | Krste | Is it possible to generate one of these cases from C with crazy uses of vreinterpret and vget/vset intrinsics? What should the compiler do for | such code? | Craig |
|
|
|
|
Re: RISC-V Vector Extension post-public review updates
I went with #3 in the updated text - this is the smallest delta from the frozen spec.
toggle quoted messageShow quoted text
Note that the worst case was something like: vfwmacc.vv v0, v0, v0, v0.t with SEW=32b, v0 is read/written as a 64b float, read as a 32b float, and read as a vector of single-bit masks in the same instruction. Krste
On Nov 15, 2021, at 2:55 PM, Krste Asanovic via lists.riscv.org <krste=sifive.com@lists.riscv.org> wrote:
|
|
|
|
Re: RISC-V Vector Extension post-public review updates
Andrew Waterman
On Mon, Nov 15, 2021 at 3:28 PM Craig Topper <craig.topper@...> wrote:
Surely possible; the fix would be to explicitly move the smaller operand to a non-overlapping register.
|
|
|
|
Re: RISC-V Vector Extension post-public review updates
Craig Topper
On Nov 15, 2021, at 3:24 PM, Krste Asanovic <krste@...> wrote:
Is it possible to generate one of these cases from C with crazy uses of vreinterpret and vget/vset intrinsics? What should the compiler do for such code? Craig
|
|
|
|
Re: RISC-V Vector Extension post-public review updates
There’s no benefit to setting vill versus just taking a trap in this case. Vill is there so we don’t have to add the first trap on a write of a particular data value, and also to provide a discovery mechanism. Krste
|
|
|
|
Re: RISC-V Vector Extension post-public review updates
Guy Lemieux
Ok, this makes the opcodes virtually useless for other instructions. Instead, shouldn't we be setting a bit similar to vill? I realize vill is only set on illegal vset* instructions; in this case it would be a new bit which is only set on executing instructions that are incompatible with the current (but otherwise valid) vtype ? Guy
|
|
|
|
Re: RISC-V Vector Extension post-public review updates
Andrew Waterman
On Mon, Nov 15, 2021 at 2:56 PM Bill Huffman <huffman@...> wrote:
Valid point, I was thinking of the scalar encoding spaces.
|
|
|
|
Re: RISC-V Vector Extension post-public review updates
Bill Huffman
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 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
I'd personally prefer #3 due to laziness, but I don't have a technical objection to #1.
|
|
|
|
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 | On Mon, Nov 15, 2021 at 2:17 PM Bill Huffman <huffman@cadence.com> wrote:On Mon, 15 Nov 2021 14:31:45 -0800, Andrew Waterman <andrew@sifive.com> 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@lists.riscv.org <tech-vector-ext@lists.riscv.org> On Behalf Of Krste Asanovic | Sent: Monday, November 15, 2021 4:58 PM | To: Guy Lemieux <guy.lemieux@gmail.com> | Cc: Krste Asanovic <krste@sifive.com>; tech-vector-ext@lists.riscv.org | 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@gmail.com> 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 |
|
|
|
|
Re: RISC-V Vector Extension post-public review updates
Andrew Waterman
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 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.
I'd personally prefer #3 due to laziness, but I don't have a technical objection to #1.
|
|
|
|
Re: RISC-V Vector Extension post-public review updates
Greg Favor
On Mon, Nov 15, 2021 at 1:05 PM Krste Asanovic <krste@...> wrote: 1) Mandate all implementations raise an illegal exception in this If I understand correctly, #3 is like #1 near-term (for conforming implementations), but keeps the possibility open to later changing from "always illegal exception" to something else. I'd vote for #1 or #3, and would be perfectly fine with #1. Greg
|
|
|
|
Re: RISC-V Vector Extension post-public review updates
Bill Huffman
I'm glad this came up. I certainly wouldn't want to try to make an implementation work for these cases. 😊
toggle quoted messageShow quoted text
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. But I'm OK with #1 or #3. Bill
-----Original Message-----
From: tech-vector-ext@lists.riscv.org <tech-vector-ext@lists.riscv.org> On Behalf Of Krste Asanovic Sent: Monday, November 15, 2021 4:58 PM To: Guy Lemieux <guy.lemieux@gmail.com> Cc: Krste Asanovic <krste@sifive.com>; tech-vector-ext@lists.riscv.org Subject: Re: [RISC-V] [tech-vector-ext] RISC-V Vector Extension post-public review updates EXTERNAL MAIL | We do have a choice of:On Mon, 15 Nov 2021 13:29:58 -0800, Guy Lemieux <guy.lemieux@gmail.com> 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 | 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
|
|
|