On Tue, 16 Nov 2021 10:18:41 +0100, Victor Moya <victor.moya@...> said:

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

A common goal in ISA design is avoiding complex implementations for
operations that are not used by software.

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

This might add the only microcode or emulation path to a design, and
for an operation that is never used.

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

Making it reserved allows for future definition as illegal, and is a
smaller deviation from the frozen spec. It does not cause
fragmentation as software, and especially compilers, will not use this
case.

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

The specification is explicit in being designed to support wide
implementations that internally rearrange data, which is the class of
machines that this change is aimed at. The current design evolved to
remove the fragmentation that would arise from making data
rearrangement visible, while also not requiring a design with explicit
upper/lower or odd/even steps to handle mixed-width operations.

Krste

| Victor

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

| Krste

|