On 2020-06-29 10:36 a.m., Krste
Asanovic wrote:
Can you focus on what would not be possible if we ratified current
proposal.
Remember EDIV is not in 1.0
It is a planned extension, that even if not implemented as
currently proposed it will likely consume at least 2 bits in
vtype.
Do you envision a possibility that it will consume no vtype bits?
The reality is that the 32bit encoding is highly dependent upon
vtype to reduce opcode space by providing common fields
dynamically.
Of course, the ideal candidates for vtype inclusion are modifiers
that will remain constant over many vector instructions.
vlmul and vsew fit the requirements.
We don't know yet if vma and vta are going to be sufficiently
variable and sufficiently constant over op sequences to be useful
in vtype.
But there they are using up 2 bits for an anticipated performance
(and in my mind "software precision/accuracy") benefit.
I agree that their inclusion in V1.0 was necessary for their
inclusion into the full ecosystem.
However, they are an example of how quickly bits can be consumed
by anticipated vs proven need.
Post V1.0 we will be more cautious in inclusion into vtype.
Fortunately, the custom space will allow explicit testing of the
relative merit of various extensions vying for inclusion in
vsetvli.
However, the fewer bits available in the base vsetvli the more
likely we will have to reject equally useful opcode extensions
from concurrent use and the most efficient code sequences.
and Vlmul=100 is reserved
I expect it will be useful for encoding parameters that do not
require lmul, e.g. one related to mask ops.
But even trying to think of an potential use for ops that don't
use lmul (or always a default lmul value of say 8) is challenging.
So, one might be temped to think that it would then be useful as
an extension flag.
However, the very ubiquitous nature of lmul would mean that the
extension would also encode lmul using 3 bits.
Thus the benefit is lost; For an alternate encoding that provides
n more bit (such as #460 that provides 6) the net increase is only
n-2 bits.
Not a winning solution in the anticipated "lmul is required"
encoding space.
Krste
minor typos; substantial correction:
