LQ/SQ don't currently have encodings

[tariqkurd-repo]

Just to make you aware of this:

riscv/riscv-isa-manual#1048

[tovine]

Thanks for the heads-up!
What do you think about the RV64 extension then, should it be left as a mention/future work but not pushed for ratification at this stage because RV128 isn't yet defined?

[tariqkurd-repo]

if you wait for RV128 you'll be waiting for a long time, so you'd need to propose encodings for LQ/SQ as suggested in that issue

[christian-herber-nxp]

Interesting, I never noticed. I would suggest going the path of least resistence, as this is targeting fast track. I.e. only have an encoding for 32-bit pair. I am not sure if 64-bit pairs are a reasonable use case, and there is no precedent of 64-bit pairs in the P extensions.

[tovine]

One more thought: even though LQ and SQ are not defined, the compressed versions (C.LQ, C.SQ, C.LQSP and C.SQSP) are defined in the C extension.
Do you think those would be worth leaving in the spec (loading 2x 64-bit values with one 16-bit instruction could be quite powerful), or should they wait for RV128 like their 32-bit counterparts?

[christian-herber-nxp]

Good catch, this changes it I would say. Very curious that this is the state of the spec. But in that case, I would just define it, i.e. include RV64 pairs, and 32-bit instructions will become available when the encoding is done.

[christian-herber-nxp]

i also just went through the unprivileged spec to confirm what you are stating. This state is just rather unbelievable. Frankly, in the fast-track process, I would check if the ARC wouldn't prefer that 32-bit encodings for LQ/SQ are defined, so that this gets resolved

[tovine]

Ok, I have updated the spec to tentatively include the compressed encodings for RV64 but with a note explaining the situation.