Questions about constraints on misa.V and xstatus.VS

[Vivvvvvvv]

Hi, base on vector spec,

"Implementations may have a writable misa.V field. Analogous to the way in which the floating-point unit is handled, the mstatus.VS field may exist even if misa.V is clear.
Note: Allowing mstatus.VS to exist when misa.V is clear, enables vector emulation and simplies handling of mstatus.VS in systems with writable misa.V."

For my understanding, the spec means when mstatus.VS=1 and misa.V=0, performing vector instruction is allowed and will not be trapped. I also checked SPIKE as SPIKE only checks if xstatus.VS=1 when performing vector instructions. So SPIKE and user manual came to an agreement. But to me, this is a bit weird as misa.V=0 should disable all vector features. Can anyone please clarify this?

Thanks a lot!

[aswaterman]

In general, when an misa bit is set, it means the feature is definitely present; when an misa bit is clear, it means the feature might not be present, but there is no guarantee that the feature is actually absent. This follows from the fact that an instruction becoming "reserved" doesn't necessitate that the instruction is illegal; it means that the instruction assumes unspecified behavior (which might be exactly equal to the behavior had the misa bit been set).

It is generally more sanitary to respect misa, and so the Spike behavior is probably an error of intent, but it doesn't violate the ISA.

[Vivvvvvvv]

So correct me if I'm wrong that performing vector instructions when xstatus.VS=1 and misa.V=0 will not trap, but the behaviors(results) is not guarenteed.

[radimkrcmar]

The spec currently defines xstatus.VS behavior only when misa.V=1:

The xstatus.VS field may exist when misa.V=0, but its behavior is not defined. The vector instructions can be illegal.