RFR: 8332900: RISC-V: refactor nativeInst_riscv.cpp and macroAssembler_riscv.cpp [v3]

[Hamlin Li]

On Fri, 31 May 2024 08:15:28 GMT, Fei Yang <fyang at openjdk.org> wrote:

> I guess that might deserve a broader discussion as it does not seem to be a RISC-V specific issue.
> 

I'm not sure if it needs be discussed broadly, as it's an implementation detail, not a shared logic in JVM. Unless someone would also like to refactor the aach64 implementation, but I'm not trying to do that.

> The RISC-V counter part: https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/riscv/assembler_riscv.hpp#L384
> 

Yes, what I mean is `extract` related things are not necessarily in nativeInst_riscv, especially when it causes too much communication bidirectionally between nativeInst and macroAssembler.

> The protocol is also there for aarch64 (movptr as an example): https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/aarch64/nativeInst_aarch64.hpp#L290

As I said, we can refer to other platforms in case they're well implemented.
But, I see no benefit and reason to put e.g. `patch_addr_in_movptr1` in macroAssembler and `is_movptr1_at` in nativeInst, I can not find the rational to do so, just because aarch64 do the similar thing? seems that's not a good reason; if it is, then how about other platforms, do they all follow aarch64 implementation details?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19459#issuecomment-2141514630