example of vmv.v.* is inconsistent with the definition in spec-1.0.pdf?

[Oxyw]

I noticed that in Appendix A.8 (page 106 of spec-1.0.pdf), there is

vmv.v.x v5, t0, v0.t

However, previously in Section 11.16 (page 55), vmv.v.* instructions were defined to have vm=1 (encoded as unmasked instructions).
It seems there might be a mismatch between the example and definition.

[dkravitz-sifive]

Though the instruction is *encoded* with vm=1, the sentence immediately prior is clear that

the vmv.v.x and vmv.v.i variants splat a scalar register or immediate to

all active elements of the destination vector register group where "active" implies taking account of all the mechanisms that could delineate excluded elements: vstart, vl, and mask (section 5.4, p24).

…

On Mon, Mar 18, 2024 at 6:04 AM WU Xieyuan ***@***.***> wrote: I noticed that in Appendix A.8 (page 106 of spec-1.0.pdf), there is vmv.v.x v5, t0, v0.t However, previously in Section 11.16 (page 55), vmv.v.* instructions were defined to have vm=1 (encoded as unmasked instructions). It seems there might be a mismatch between the example and definition. — Reply to this email directly, view it on GitHub <#947>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ASDNWSMWJBYMM7YFFOVNMUDYY233XAVCNFSM6AAAAABE3ID6HGVHI2DSMVQWIX3LMV43ASLTON2WKOZSGE4TCNZWGA4TANI> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[topperc]

The assembly parser does not allow v0.t as an operand to vmv.v.x. So the code is invalid.

[aswaterman]

I suppose we could've made vmv.v.x vd, rs, v0.t a pseudo-op for vmerge.vxm vd, vd, rs, v0, though that ship has probably sailed and it doesn't matter much anyway.

In any event, @ericlove fixed this bug last year in 5b04775 as part of a rewrite to use a more accurate algorithm.