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

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

(newType >> 8) != 0; This last clause in spike code would seem to catch the case in question ?? Krste

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

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

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

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

Put that value in a register and use the vsetvl instruction which takes a register argument for vtype. Krste

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

Historically, vector machines have employed a wide variety of strategies here. Simply not executing past a vector memory access until exception checks have been performed is the simplest thing to do.

Hello all, Could somebody please comment on the basic options related to chaining vector loads? It is easy to see how arithmetic vector instructions can be chained together. However, if a vector load

I'm trying to understand the reason for this. Do you need more than 32 register variables for some algorithm? (of course unrolling a loop can use arbitrary numbers of registers) How will you address

Thank you for this very important consideration. On 2021-10-05 6:29 a.m., Feng Chuang wrote: Yes. The expectation is that many of the current constraints will be relaxed

hi Krste and all friends, Per my understanding, if I extend the vector architecture register number (to be larger than 32) and extend maximum LMUL value to be larger than 8, current vector extension

Hi Mick, This is what I do for 32-bit RISC-V Vector on ubuntu1804, admittedly it took me a long time to find a combination that worked and I had help to get the correct switches: Risc-V

That's true. :) Providing full support for Vector extension is already on the todo-list of CAS/PLCT Lab. Vector extension is one of the extensions that are included in an all-in-one developer

I’ve made a frozen release of version 1.0 ready for public review. The release is tagged: https://github.com/riscv/riscv-v-spec/releases/tag/v1.0 and I’ve attached pdf below. The main repo has

I don't do LLVM work, and can't offer any suggestions there. In general, I'd say that if you don't have a half dozen people doing assembler, compiler, simulator, kernel, library, etc work, then you

I see. I'm ashamed to admit, but I am now really lost between all the permutations of Vector ext. revisions and toolchain versions that I've attempted without success. At this point, I'd just like to

V-extension version 1.0 hasn't been frozen yet. Its second release candidate was posted just yesterday: https://github.com/riscv/riscv-v-spec/releases/tag/v1.0-rc2 I wouldn't expect toolchain support