Issue categorization - #460
I disagree that #460 should be deferred until after V1.0.toggle quoted message Show quoted text
Although I agree that the proposal itself can be implemented in a manner consistent with the current vsetvli definition,
I disagree that the larger issue of how to expand vsetvli immediate bits is sufficiently addressed to make the decision to defer.
As a result I ask that at least the larger issue be addressed for V1.0.
As background, #440 is a refinement of an approach to encode vtype bits in vd and vs2 fields.
The details are on github and references to like prior proposals
I posted on #440 this response to labeling it "Resolve after V1.0".:
Although technically not a part of this proposal, the decision to defer until after V1.0 would greatly impact proposal #460.
As we are down to one vsetvli immediate bit, and all used bits consume all combinations as valid, we are at the cusp where we should consider the impacts of expansion.
Expansion requires providing at least one of the following:
Splitting configuration over two immediate format instructions is
Option 1 must be decided before V1.0 (otherwise it becomes an option 4 with two overlapping instructions)
Options 2 through 5 can be deferred until after V1.0 but each have impacts to
Options 2 through 4 have the additional concerns of:
Deferred options 2,3 and 5 need not trap on V1.0 machines as vill would be set if the remaining bit is used to differentiate.
Deferred option 4 will always trap on V1.0 machines.
Option 5 is a novel approach to the problem.
On 2020-06-28 3:27 p.m., Krste Asanovic wrote:
I made a pass over the spec repo, adding red labels for “resolve for v1.0’ , versus yellow labels for "resolve after v1.0”. I also cleaned up and closed some other issues. "Resolve after’ should not be taken to imply we will take on the suggestion, just that it won’t be in 1.0. Please email list if you’re unhappy about any of these labels or closed issues. Krste
|1 - 1 of 1|