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






Join tech-vector-ext@lists.riscv.org to automatically receive all group messages.