On 02.07.2024 17:51, Oleksii wrote: > On Tue, 2024-07-02 at 14:08 +0200, Jan Beulich wrote: >>> --- a/xen/arch/riscv/include/asm/cmpxchg.h >>> +++ b/xen/arch/riscv/include/asm/cmpxchg.h >>> @@ -18,6 +18,19 @@ >>> : "r" (new) \ >>> : "memory" ); >>> >>> +/* >>> + * To not face an issue that gas doesn't understand ANDN >>> instruction >>> + * it is encoded using .insn directive. >>> + */ >>> +#ifdef __riscv_zbb >>> +#define ANDN_INSN(rd, rs1, rs2) \ >>> + ".insn r 0x33, 0x7, 0x20, " rd ", " rs1 ", " rs2 "\n" >> >> Why 0x33? Just like in the other patch you used MISC_MEM (as >> suggested, >> for being more descriptive), you want to use OP here. Then >> Reviewed-by: Jan Beulich <jbeul...@suse.com> >> (and I'd certainly be okay making the change while committing) > > According to Volume 1, Unprivileged Specification version 20240411 the > andn instruction looks > like: > 31 25 24 20 19 15 14 12 11 7 6 0 > 0 1 0 0 0 0 0 rs2 rs1 1 1 1 rd 0 1 1 0 0 1 1 > OP > > This instruction is R-type. According to the gcc manual > ( https://sourceware.org/binutils/docs/as/RISC_002dV_002dFormats.html > ): > R type: .insn r opcode6, func3, func7, rd, rs1, rs2 > +-------+-----+-----+-------+----+---------+ > | func7 | rs2 | rs1 | func3 | rd | opcode6 | > +-------+-----+-----+-------+----+---------+ > 31 25 20 15 12 7 0 > > so opcode6 in case of andn is 0x33 (0110011)
Right. And "OP" is the identifier you can use with .insn to get 0x33 without needing to write 0x33. As said - the requested replacement is solely to help readability a little. Jan
