First draft vector parameters #1245
Conversation
There was a problem hiding this comment.
Good work, and much appreciated!
Unsurprisingly, perhaps, I have a number of comments to hopefully improve the PR.
By the way, I noted some text that may require additional parameters when reviewing the VFREDUSUM parameter:
A different floating-point range and precision may be chosen for the result of each operator. A node where one input is derived only from elements masked-off or beyond the active vector length may either treat that input as the additive identity of the appropriate EEW or simply copy the other input to its output. The rounded result from the root node in the tree is converted (rounded again, using the dynamic rounding mode) to the standard floating-point format indicated by SEW. An implementation is allowed to add an additional additive identity to the final result.
I didn't do an exhaustive search through the chapter.
| value. | ||
| schema: | ||
| type: integer | ||
| enum: [8, 16, 32, 64] |
There was a problem hiding this comment.
The spec has this:
In the standard extensions, SEWMIN=8.
So, do we need to support a parameter for this, given that only 8 is "standard"?
Related, where did these 4 values come from?
There was a problem hiding this comment.
In the testing framework we are developing for RISC-V ACT 4.0 we include SEW_MIN as a parameter. Even though it is not currently in a standard extension to use anything other than SEW_MIN=8, it is still a valid vector implementation to have a different SEW_MIN. As far as we can tell, SEW_MIN is completely arbitrary in non-standard extensions meaning it can be any SEW. For example, we interpret that a vector unit that only supports an SEW of 32 to be a valid implementation (SEW_MIN=32 and ELEN = 32).
| VECTOR_AGNOSTIC_BEHAVIOR: | ||
| description: | ||
| When a set is marked agnostic, the corresponding set of destination | ||
| elements in any vector destination operand can either retain the value | ||
| they previously held, or are overwritten with 1s. | ||
| schema: | ||
| type: string | ||
| enum: ["never_overwritten", "custom"] |
There was a problem hiding this comment.
This appears to be parameterizing a specific possible implementation of "agnostic" for a behavior which can even be non-deterministic. Is there value in doing so? (Honest question.)
There was a problem hiding this comment.
I think this is a completely fair interpretation; I just thought there might be some value to even stating in a custom parameter "undeterministic." I think it would also be useful for a parameter to state that this behavior is never exercised, thats why I included "never_overwritten"
| For a given supported fractional LMUL setting, implementations must support | ||
| SEW settings between SEW~MIN~ and LMUL * ELEN, inclusive. |
There was a problem hiding this comment.
This would seem to be a normative rule, rather than a parameter. (But don't trust my interpretation! 😉 )
There was a problem hiding this comment.
The issue below discusses this issue. The normative rule above simply states what is required to be implemented. For example, it doesnt state that SEW 64 LMUL 1/2 cannot be supported. Therefore in my mind I see it as up to the designer to allow for this implementation or not. Supporting vs not supporting these cases would produce a different result when executing the same program: that is why it should be a parameter in my mind.
| type: string | ||
| enum: ["no_change", "custom"] |
There was a problem hiding this comment.
Could use more eyes on this one:
- Is the parameter just about
vfredusumand "NaN" or should "no active elements" be part of the parameter name as well? In other words, is it specific to the case of "no active elements"? - Does it need to be a parameter at all, given the description is in an "informative note" and not in the regular text?
typo Co-authored-by: Paul Clarke <[email protected]> Signed-off-by: jacassidy <[email protected]>
Syntax for parameter names Co-authored-by: Paul Clarke <[email protected]> Signed-off-by: jacassidy <[email protected]>
Typo Co-authored-by: Paul Clarke <[email protected]> Signed-off-by: jacassidy <[email protected]>
punctuation Co-authored-by: Paul Clarke <[email protected]> Signed-off-by: jacassidy <[email protected]>
duplicate Co-authored-by: Paul Clarke <[email protected]> Signed-off-by: jacassidy <[email protected]>
Co-authored-by: Paul Clarke <[email protected]> Signed-off-by: jacassidy <[email protected]>
Co-authored-by: Paul Clarke <[email protected]> Signed-off-by: jacassidy <[email protected]>
Co-authored-by: Paul Clarke <[email protected]> Signed-off-by: jacassidy <[email protected]>
Co-authored-by: Paul Clarke <[email protected]> Signed-off-by: jacassidy <[email protected]>
Co-authored-by: Paul Clarke <[email protected]> Signed-off-by: jacassidy <[email protected]>
spec/std/isa/ext/V.yaml
Outdated
| MSTATUS_VS_EXISTS: | ||
| description: | | ||
| Analogous to the way in which the floating-point unit is handled, the `mstatus.VS` field may exist even if `misa.V` is clear. | ||
| schema: | ||
| type: boolean |
There was a problem hiding this comment.
This is already covered by the MSTATUS_VS_LEGAL_VALUES parameter.
There was a problem hiding this comment.
does this also apply to VSSTATUS_VS_EXISTS, meaning should I instead make a parameter for legal values instead of one for if it exists or not.
better description Co-authored-by: Paul Clarke <[email protected]> Signed-off-by: jacassidy <[email protected]>
3 participants
Trying to pickup on any mentions of "implementation specific" choices that could be made by a designer of the RISC-V Vector Extension. Descriptions are direct quotes from the spec for easy search. Some parameters may be unneeded as they wouldnt affect instruction-level output behavior but I figured including more rather than less could only be benificial. Names are tentative.