Re: RISC-V Vector Extension post-public review updates
toggle quoted message Show quoted text
From an ISA definition point of view it doesn't make sense to forbid properly formed operations to benefit a specific hardware implementation. It's an ugly hack.
If a given hardware implementation can't handle it in an optimal way and it really doesn't have real software use (ie, performance is irrelevant) it can just trigger a slow path (microcode sequence or trap to software emulation).
But given that it isn't the first case in the spec it isn't really much of a problem. Between making halfway hacks, I think it's better to make it completely illegal (option #1) than to add additional fragmentation that may affect compilers with #2 or #3.
If the vector specification is required to be optimal for a specific hardware implementation better make it explicitly so and not go in roundabout ways..
On Mon, Nov 15, 2021 at 10:05 PM Krste Asanovic <krste@...> wrote:
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 specification allows some instructions to have two vector
source operands read from the same vector register but with different
EEW. For example, a vector indexed store with the index vector and
data vector overlapping, but different EEW. Or a widening vector add
(vwadd.wv) where the two vector sources overlap but have different
EEW. This complicates implementations that internally restripe the
vector data (e.g., internal SLEN), and does not have a valid software
use (cue folks furiously trying to construct one...).
The proposal is to allow implementations to raise an illegal
instruction exception in this case. I believe this is an important
and necessary change to accomodate internal striping. In practice,
this change has no impact on software.
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 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
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.