Open anderslindgren-iar opened 3 months ago
When using Zdinx, the FSGNJ.D instruction is used for moving register pairs. If you have a P extension, there will also have many options for creating a move pseudo instruction (e.g. any add operation with x0/zero as one source). It might make sense to recommend for a move instruction to be a subextension of P, so that one can have the move instruction without subscribing to the entirety of P.
One of the reasons why I proposed it to be included here is to avoid yet another subextension.
Why? Because every subextension increases the number of possible core combinations. If someone would like to provide prebuilt libraries (like the runtime library of a compiler), they are facing a combinatorical explosion.
Even today, compiler vendors are forced to select a handful of extension to be used when building runtime libraries, typically the base ISA and with/without some of the basic incompatible extensions. Other extensions like the one proposed here will probably not be used. This will lead to a situation where parts of an application won't be able to utilize the full power of the device.
For me, grouping basic instructions that operate on register pairs into the same extension would make more sense than just providing load:s and store:s. In addition to a register pair move, moves to/from a 64 bit floating-point register and a register pairs would also be useful for D devices. If you would provide one extension, chances are higher that prebuilt libraries would use it.
I have been advocating about this for years -- unfortunately, the RISC-V world is gravitating a world where hardware vendors have a smorgasbord of features to pick from, despite this being damaging for tool and library providers.
I can sympathize with everything you say, and we should find a solution for it. Using a floating point instruction for pair move will not be it, as that operates on x-registers only in the case of Z*inx. The P extension encodings have not yet been done. I think the best course of action is to consult with the P-extension task group, how this could be addressed. Possibly, P could define another subextension that pulls in all necessary pair extensions.
In code that work with register pairs, a common operation is moving values between register pairs.
Even though it is not related to loading and storing values, a move instruction that operates on register pairs would complement the defined instructions nicely. The instruction could operate on even register pairs, and have the same special case when copying from
x0
.The instruction could be named something like
mvp rd, rs
ormv (rd2,rd1), (rs2,rs1)
.Side note: When zdinx is used, the
fmv
instruction performs register pair moves.