[RV64] encoding of "packw" will conflict with "zext.h" if rs2 field of "packw" is equal to zero
yichanfeng opened this issue · comments
Hi,
I have a question about instruction encoding.
=> Do we need to adjust the instruction encoding of zext.h (bitmanip) or packw (crypto) under RV64 configuration because the encoding of packw will conflict with zext.h if rs2 field of packw is equal to zero ?
[RV64, Bitmanip] "zext.h" encoding
[31:25]: 0000100, [24:20]: 00000, [19:15]: rs field, [14:12]: 100, [11:7]: rd field, [6:0]: 0111011
[RV64, Crypto] "packw" encoding, encoding is the same when rs2 = 0
[31:25]: 0000100, [24:20]: rs2 field, [19:15]: rs1 field, [14:12]: 100, [11:7]: rd field, [6:0]: 0111011
I had raised the same issue on "crypto" task group.
They suggested me that I should ask the encoding issue here.
Thanks!
The encoding is the same because they are the same instruction. Except that zbb only includes a subset of packw, the subset that has the one field set to zero.
Thank you for the quick reply.
I have one more question.
If a processor core supports both of bitmanip and crypto extension, what is the suggested instruction usage ?
- use "zext.h" for 16-bit zero extension and use "packw" for non-zero extension.
- always use "packw" if both of them are supported
For readable assembly code, I would suggest using zext.h when you want a zext.h operation, and packw when you want a packw operation. That is what gcc does. Otherwise it doesn't matter, as they are the same instruction.
The disassembler will use zext.h if zbb and it is a zext.h, otherwise it will use packw if zkbk.
Also note that GNU as supports zext.h as a macro that expands to two shifts when zbb is not supported. packw is not supported without zbkb.
Hmm. Looks like the assembler is missing a case where we can support zext.h if zbkb but not zbb by assembling it as a packw. That looks like a bug, but an obscure one, since I expect zbb to be much more common than zbkb.
Thank you for the quick reply.