Date   

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

Krste Asanovic
 

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 Mon, 15 Nov 2021 15:28:25 -0800, Craig Topper <craig.topper@...> said:
| On Nov 15, 2021, at 3:24 PM, Krste Asanovic <krste@...> wrote:
| On Nov 15, 2021, at 3:13 PM, Guy Lemieux <guy.lemieux@...> wrote:

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

| 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

Krste Asanovic
 

I went with #3 in the updated text - this is the smallest delta from the frozen spec.

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@...> wrote:


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

| 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

|





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:
On Nov 15, 2021, at 3:24 PM, Krste Asanovic <krste@...> wrote:



On Nov 15, 2021, at 3:13 PM, Guy Lemieux <guy.lemieux@...> wrote:

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.

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?

Surely possible; the fix would be to explicitly move the smaller operand to a non-overlapping register.


Craig





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

Craig Topper
 

On Nov 15, 2021, at 3:24 PM, Krste Asanovic <krste@...> wrote:



On Nov 15, 2021, at 3:13 PM, Guy Lemieux <guy.lemieux@...> wrote:

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.

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

Krste Asanovic
 



On Nov 15, 2021, at 3:13 PM, Guy Lemieux <guy.lemieux@...> wrote:

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.

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
 

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.

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:

 

 

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.


Valid point, I was thinking of the scalar encoding spaces.

 

      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










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










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.

Krste

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

| 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

|


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











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

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

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


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

Krste Asanovic
 

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


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

Guy Lemieux
 

That’s great news, thanks Krste!

The current specification allows some instructions to have two vector
source operands read from the same vector register but with different
EEW. 

(cue folks furiously trying to construct one...)

haha i tried but can’t think of a use case !!

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


RISC-V Vector Extension post-public review updates

Krste Asanovic
 

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: reliably set vtype.vill

Tim Newsome
 

As usual, Krste is completely right. This was a matter of OpenOCD not doing what I thought it was doing. Thanks for your help.

Tim

On Mon, Nov 1, 2021 at 10:32 AM Krste Asanovic <krste@...> wrote:
Put that value in a register and use the vsetvl instruction which takes a register argument for vtype.

Krste

On Nov 1, 2021, at 9:46 AM, Tim Newsome <tim@...> wrote:

I'm trying to set vill, and I can't think of a reliable way to do it.

This comes up when OpenOCD (a debugger) connects to a RV32 target where vtype contains (for instance) 0x80000000. The user asks to read the vector registers, and the debugger wants to use vtype so it can shift the register. When done, it wants to restore the original value so that there is no observable impact to the debugging.

Is there a way that I can write 0x80000000 to vtype?

Tim


Re: reliably set vtype.vill

Bill Huffman
 

Still could be worth a non-normative comment saying something like “even though there may not be a separate bit for vill, if the source register of a vsetvl instruction has bit XLEN-1 set, vtype will be set to illegal.”

 

     Bill

 

From: tech-vector-ext@... <tech-vector-ext@...> On Behalf Of Krste Asanovic
Sent: Monday, November 1, 2021 2:09 PM
To: Krste Asanovic <krste@...>
Cc: Tim Newsome <tim@...>; tech-vector-ext@...
Subject: Re: [RISC-V] [tech-vector-ext] reliably set vtype.vill

 

EXTERNAL MAIL

(newType >> 8) != 0;

 

This last clause in spike code would seem to catch the case in question ??

 

Krste



On Nov 1, 2021, at 11:03 AM, Krste Asanovic via lists.riscv.org <krste=sifive.com@...> wrote:

 

From 1.0 spec:

"
The vsetvl variant operates similarly to vsetvli except that it takes a vtype value from rs2 and can be used for context restore.

If the vtype setting is not supported by the implementation, then the vill bit is set in vtype, the remaining bits in vtype are set to zero, and the vl register is also set to zero.


Could be a bug in spike.

Krste



On Nov 1, 2021, at 10:58 AM, Tim Newsome <tim@...> wrote:

Thanks. spike infers vill from the other bits when executing vsetvl (link), so the only way to set vill is to find an illegal combination from the other bits. The spec doesn't seem to explicitly say that vill is writable, only that it gets set when the other bits are invalid. Did I miss something? Is a clarification needed?

Tim

On Mon, Nov 1, 2021 at 10:32 AM Krste Asanovic <krste@...> wrote:
Put that value in a register and use the vsetvl instruction which takes a register argument for vtype.

Krste


On Nov 1, 2021, at 9:46 AM, Tim Newsome <tim@...> wrote:

I'm trying to set vill, and I can't think of a reliable way to do it.

This comes up when OpenOCD (a debugger) connects to a RV32 target where vtype contains (for instance) 0x80000000. The user asks to read the vector registers, and the debugger wants to use vtype so it can shift the register. When done, it wants to restore the original value so that there is no observable impact to the debugging.

Is there a way that I can write 0x80000000 to vtype?

Tim

 





 


Re: reliably set vtype.vill

Krste Asanovic
 


(newType >> 8) != 0;

This last clause in spike code would seem to catch the case in question ??

Krste

On Nov 1, 2021, at 11:03 AM, Krste Asanovic via lists.riscv.org <krste=sifive.com@...> wrote:

From 1.0 spec:

"
The vsetvl variant operates similarly to vsetvli except that it takes a vtype value from rs2 and can be used for context restore.

If the vtype setting is not supported by the implementation, then the vill bit is set in vtype, the remaining bits in vtype are set to zero, and the vl register is also set to zero.


Could be a bug in spike.

Krste


On Nov 1, 2021, at 10:58 AM, Tim Newsome <tim@...> wrote:

Thanks. spike infers vill from the other bits when executing vsetvl (link), so the only way to set vill is to find an illegal combination from the other bits. The spec doesn't seem to explicitly say that vill is writable, only that it gets set when the other bits are invalid. Did I miss something? Is a clarification needed?

Tim

On Mon, Nov 1, 2021 at 10:32 AM Krste Asanovic <krste@...> wrote:
Put that value in a register and use the vsetvl instruction which takes a register argument for vtype.

Krste

On Nov 1, 2021, at 9:46 AM, Tim Newsome <tim@...> wrote:

I'm trying to set vill, and I can't think of a reliable way to do it.

This comes up when OpenOCD (a debugger) connects to a RV32 target where vtype contains (for instance) 0x80000000. The user asks to read the vector registers, and the debugger wants to use vtype so it can shift the register. When done, it wants to restore the original value so that there is no observable impact to the debugging.

Is there a way that I can write 0x80000000 to vtype?

Tim







Re: reliably set vtype.vill

Bill Huffman
 

I think that deserves at least a non-normative comment. I think many won't intuit from what's below that a bit that's otherwise stated doesn't need to exist will be "set" that way.

But I agree setting it the way you said is the way it should be done.

Bill

-----Original Message-----
From: tech-vector-ext@... <tech-vector-ext@...> On Behalf Of Krste Asanovic
Sent: Monday, November 1, 2021 2:04 PM
To: Tim Newsome <tim@...>
Cc: tech-vector-ext@...
Subject: Re: [RISC-V] [tech-vector-ext] reliably set vtype.vill

EXTERNAL MAIL


From 1.0 spec:

"
The vsetvl variant operates similarly to vsetvli except that it takes a vtype value from rs2 and can be used for context restore.

If the vtype setting is not supported by the implementation, then the vill bit is set in vtype, the remaining bits in vtype are set to zero, and the vl register is also set to zero.


Could be a bug in spike.

Krste


On Nov 1, 2021, at 10:58 AM, Tim Newsome <tim@...> wrote:

Thanks. spike infers vill from the other bits when executing vsetvl (link), so the only way to set vill is to find an illegal combination from the other bits. The spec doesn't seem to explicitly say that vill is writable, only that it gets set when the other bits are invalid. Did I miss something? Is a clarification needed?

Tim

On Mon, Nov 1, 2021 at 10:32 AM Krste Asanovic <krste@...> wrote:
Put that value in a register and use the vsetvl instruction which takes a register argument for vtype.

Krste

On Nov 1, 2021, at 9:46 AM, Tim Newsome <tim@...> wrote:

I'm trying to set vill, and I can't think of a reliable way to do it.

This comes up when OpenOCD (a debugger) connects to a RV32 target where vtype contains (for instance) 0x80000000. The user asks to read the vector registers, and the debugger wants to use vtype so it can shift the register. When done, it wants to restore the original value so that there is no observable impact to the debugging.

Is there a way that I can write 0x80000000 to vtype?

Tim


Re: reliably set vtype.vill

Alex Solomatnikov
 

vsetvli x1, x0, e8, m8
vsetvli x0, x0, e16, m8

Alex

On Mon, Nov 1, 2021 at 9:46 AM Tim Newsome <tim@...> wrote:
I'm trying to set vill, and I can't think of a reliable way to do it.

This comes up when OpenOCD (a debugger) connects to a RV32 target where vtype contains (for instance) 0x80000000. The user asks to read the vector registers, and the debugger wants to use vtype so it can shift the register. When done, it wants to restore the original value so that there is no observable impact to the debugging.

Is there a way that I can write 0x80000000 to vtype?

Tim

141 - 160 of 862