Re: RISC-V Vector Extension post-public review updates
[...] it seems to me
that the current issue creates a currently rare, and undesirable, situation
where an illegal exception trap depends on a significantly complex
interaction between an instruction and the machine state.
Almost all vector instructions already have to check their vector operands to make sure the register numbers are compatible with (dynamic) LMUL. This is further complicated in, e.g., the case of mixed-width instructions' source-destination register overlap constraints. The (static EEW) loads/stores also have to do similar checking, since EMUL depends on (dynamic) SEW. I'd argue that the dependence on vtype of the validity of vector register numbers is pervasive, not rare. (I won't argue about un/desirability.)
Best,
Nick
On Tue, Nov 16, 2021, 7:53 AM ghost <ghost@...> wrote:
> 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 implementations (doesn't affect software), and we would not
> reuse
> this state/encoding for other purposes.
>
> 2) Allow either correct execution or illegal exception (as with
> misaligned).
>
> 3) Consider "reserved", implying implementations that support it are
> non-conforming unless we later go with 2).
>
> I'm assuming we're going to push to ratify 1) unless I hear strong
> objections.
I agree that #1 is the least unfortunate of the alternatives, but I want to
raise a flag because I think there are larger considerations.
AFAIK, the vector extensions are unique among proposed non-privileged
extensions in their extensive functional dependency on machine state other
than the instruction. Avoiding this kind of dependency seems to have been a
consistent and important goal (one of many, of course) in previous designs.
For example, including a rounding mode in every floating point instruction,
even the FMA group, multiplied the number of code points for these
instructions by 8, even though it is not clear (at least to me) how
important the use cases are. (IMO this might tend to support ds2horner's
proposal to use 48- or 64-bit instructions for some of the vector
capability, but that is off topic for the present discussion; and I can see
a counter-argument that using machine state simplifies pipelining setup that
might depend on that state.) Because of this dependency, it seems to me
that the current issue creates a currently rare, and undesirable, situation
where an illegal exception trap depends on a significantly complex
interaction between an instruction and the machine state. Just something to
bear in mind for the future.
--
L Peter Deutsch <ghost@...> :: Aladdin Enterprises :: Healdsburg, CA
Was your vote really counted? http://www.verifiedvoting.org