On Fri, 1 May 2020 at 02:55, Richard Henderson <richard.hender...@linaro.org> wrote: > I'm not 100% sure how best to handle the swapped operands issue. I don't > think > we want to do it here in gen_gvec_srshl, because we don't have the same > reverse > operand problem in the aarch64 encoding, and I'm looking forward to re-using > this generator function in aa64 and sve2. > > Maybe it would be better to have > > @3same .... ... . . . size:2 .... .... .... . q:1 . . .... \ > &3same vm=%vm_dp vn=%vn_dp vd=%vd_dp > @3same_rev .... ... . . . size:2 .... .... .... . q:1 . . .... \ > &3same vn=%vm_dp vm=%vn_dp vd=%vd_dp > > and swap the operands to "normal" during decode.
Yeah, I guess so. It's a little confusing because the operands are going to appear with the "wrong" names in the trans_ functions, but we can hopefully deflect some of that with a suitable comment by the @3same_rev format definition. I think that all the affected insns have asm formats like VSHL <Dd>, <Dm>, <Dn> in contrast to eg VSUB <Dd>, <Dn>, <Dm> so it's effectively just that the field names in the official insn definition are backwards from what you'd expect. thanks -- PMM
