|
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
|
|
|
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
toggle quoted message
Show quoted text
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
This last clause in spike code would seem to catch the case in question ??
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
This last clause in spike code would seem to catch the case in question ??
Krste
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.KrsteOn 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
|
|
|
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
toggle quoted message
Show quoted text
-----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
|
|
|
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
|
|
|
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
toggle quoted message
Show quoted text
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
|
|
|
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
Put that value in a register and use the vsetvl instruction which takes a register argument for vtype.
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
|
|
|
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
|
|
|
