zext.h and packw are both real instructions with overlapping encodings
Closed this issue · 5 comments
The functionality of zext.h (Zbb) overlaps with packw with rs2=0 (Zbkb)
Zbkb doesn't imply Zbb. Maybe that the intention but I can't see that in the manual.
It does say it's a subset though:
34.3.1. Zbkb - Bitmanip instructions for Cryptography
These are a subset of the Bitmanipulation Extension Zbb which are particularly useful for
Cryptography.
If Zbb is present without Zbkb then zext.h is a real instruction. If Zbkb is also included then zext.h is a pseudo.
This is a bit weird - how is this supposed to be defined?
What’s your goal in raising this issue? There’s no definitional problem.
Just to understand how this is supposed to work.
It looks like it's been raised before: riscv/riscv-bitmanip#170
I'd say it worth adding note about how to interpret the combination of Zbkb and Zbb - as the instructions overlap. People will continue to trip over this otherwise.
Are there any other examples of duplicate definitions?
packw with rs2=x0 is the same as zext.h, as you pointed out. Same encodings, same semantics.
Closing this issue as it's not clear what problem there is to be solved.
packwwith rs2=x0 is the same aszext.h, as you pointed out. Same encodings, same semantics.Closing this issue as it's not clear what problem there is to be solved.
It's packw on RV64 and pack on RV32.
Should the assemblers encode zext.h using the pack(w) encoding if Zbkb is enabled with Zbb? I think right now they will falllback to slli+srli in that scenario.
Yeah, since pack[w] is a superset of zext.h, it makes sense for zext.h to use the pack[w] encoding in any situation that the full pack[w] instruction is provided (which for now I guess just means Zbkb).