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

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

That’s great news, thanks Krste! … haha i tried but can’t think of a use case !! I don’t have a strong opinion, but I prefer a route that allows us to recover those instruction encodings —

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

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