1. Tech-Vector-Ext
  2. Topics

reliably set vtype.vill

Tim Newsome
 

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

Krste Asanovic
 

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

Tim Newsome
 

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

Krste Asanovic
 

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

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

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

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






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

 





 

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

1 - 9 of 9