Ahead of the vector meeting I would like to see if we can address or at least get direction on some of the flagged for pre-v1.0 resolution.

There are 3 related flagged issues that all deal with vstart.

493 - unbind vstart from element index

510 - add element index to vstart for segment loads and stores

532 - define vstart as an opaque value (some values will have specific meanings

These have in common redefining vstart.

#493 proposes that the vstart value not have a one to one mapping from its value to the usual vl ordering.

               This was motivated in part by SLEN considerations that are now invisible to the ISA architecture.
               However, included is the consideration that some operations , e.g.  cryptography may desire restart part of the way through the operation.
                      This even if only one element is contained in the vlen*8 register set.
                      Clearly insufficient internal state is expressed it only zero and 1 are allowed values.

#510 proposes the element position within a segmented load/store is identified in vstart, not just the group position. **

            Most of the discussion relates to which should be identified, element position or group position.
            POR is group position and it was substantially defended as the incumbent definition.
            The POR substantially limits an implementations options, intended for the greater good.
            Thus the question of where and how the additional "element within group" information should be stored did not progress.
            However, even if segmented load/stores will settle on restart granularity of groups or elements,
                  the larger question of alternate representation of restart information for "special" cirumstances has been raised,
                  as it has in #493.

#532 proposes that vstart be defined as a value that will be treated as opaque at the ISA level.

           No intrinsic meaning should be inferred directly from the value in vstart.

           It is assured only to be a value used to instruct the implementation to restart the instruction from either a) the exception element or b) by adding 1 to the vstart value, the next element.

           The proposal allows for implementations to provide a mechanism to provide additional trap information, including related element at exception.

           Escape mechanisms to convey that the index is simply embedded in the rightmost bits of vstart is discussed as a concession

                to the expectation that plain text identification of the element "active" at the time of the exception is valuable information and sufficient in most cases for restart handling.

My request for the meeting is to poll the group to respond agree, disagree or abstain on the following..

         1)   the POR [vstart is the plain text number indicating the next element at which to resume] is sufficient for v1.0,
                  Any augmenting of vstart or adding new facilities [e.g. csr] can be addressed later.
                  The ecosystem changes can also be made later as we expect the changes required to be specific to new functionality (crypto, ediv, etc.).

          2) we  identify specific special cases that we believe are desired by ecosystem [ element within segment group, phased restart of crypto ops, etc.]
                  and make specific allowance for supporting fields in vstart.
                   Low order bit will still identify the item [element, segment, crypto term, etc.] specific to the instruction.
                   Other fields will be populated according to the nature of the operation and the element type.

         3)  vstart be considered opaque as above with the escape mechanism that then reduces to the current POR.
                   The ecosystem will need to handle the general case in which the element of exception must be determined by other means than low bits in vstart.
                   Exception handlers can no longer resume at an arbitrary element in the instruction and have a reasonable expectation that the restart will work as expected.

          4) opaque vstart without an escape signature in vstart. In all cases an alternate mechanism will be required to identify the element "of exception".

          5) further investigation is still required before these decisions can be made.

           

** (and presumably  any future segmented operation)