Unexpected jalpseudo/jalrpseudo instructions

[4a6f656c]

Commit 13be4ee added additional pseudo instructions, including these two lines in rv_i:

$pseudo_op rv_i::jalr   jalr rs1    31..20=0 14..12=0 11..7=0x01 6..2=0x19 1..0=3
$pseudo_op rv_i::jal    jal  jimm20                   11..7=0x01 6..2=0x1b 1..0=3

These result in ./parse.py -go generating AJALPSEUDO and AJALRPSEUDO instructions, which are unexpected. It seems rather strange to alias an instruction to itself - the only difference between these and the original definitions appears to be that the register is hardcoded to X1. Have these been misnamed or added in error?

[4a6f656c]

/cc @AFOliveira @aswaterman

[AFOliveira]

These result in ./parse.py -go generating AJALPSEUDO and AJALRPSEUDO instructions, which are unexpected. It seems rather strange to alias an instruction to itself - the only difference between these and the original definitions appears to be that the register is hardcoded to X1. Have these been misnamed or added in error?

That's on purpose. If you check the ASM Manual (the exact links are on PR #278) that's how the pseudo-instructions are specified. I added the "pseudo" naming for those two variables so that the re-definition would not break any output already being used downstream. Moreover, I believe the reason for x1 being hardcoded there is that x1 actually is the Return Address specified on RISC-V ABI, but I guess @aswaterman is the best person to answer to that.

[aswaterman]

I believe the reason for x1 being hardcoded there is that x1 actually is the Return Address specified on RISC-V ABI

Right.

[4a6f656c]

I understand why x1 is hardcoded here, however it seems to make little sense to provide an instruction called AJALPSEUDO which has this encoding. In reality, this is an assembly implementation issue whereby if no register is specfied for the AJAL instruction, it should default to x1.

I guess we'll just have to work around this by disabling the inclusion of pseudo-instructions for Go.

[AFOliveira]

This repo being a source of information, I believe it should be as complete and possible and therefore hold the most information possible. However, I see how the changes may affect downstream application, and now that you're switching that I agree that passing pseudo as a flag may work best.

@IIITM-Jay Technically, it would also solve #289