Register pair instructions should use a `(rx, ry)` syntax

[anderslindgren-iar]

When reading and writing assembly programs, it must be 100% clear where processor registers are accessed. Normally, all processor registers that you access are directly visible in the assembly source file. A programmer can use basic tools like "search" in their text editor to find all occurrences of a specific processor register.

However, the new instructions that operate on registers pairs doesn't follow this basic principle. For example, in the following snippet, it looks like t1 is defined but never used.

    li t0, 0x12345678
    li t1, 0x9abcdef
    sd t0, 0(t2)

If you tweak the syntax so that register pair instructions use the syntax (t1, t0) the code will be easier to understand, since it would be clear where t1 is used:

    li t0, 0x12345678
    li t1, 0x9abcdef
    sd (t1, t0), 0(t2)

My guess that the single register syntax was picked since the underlying encoding use a single register. However, for an assembly programmer, it is more important that the syntax corresponds to the semantic of the instruction rather than the encoding.

[tovine]

Good point, can we expect tools to understand both these syntax variants (and support emitting them in an objdump)? I agree it's more readable, but since the upper register in the pair is locked to (lower_one+1) then it doesn't present any actual choice. I assume software tools can enforce this restriction?

Also, how is this handled for the Zpsfoperand P-extension? I think it makes sense to align these two as much as possible.

[anderslindgren-iar]

If you define the syntax in the specification, then you should be able to expect that tools support them.

However, I don't necessarily think it's a good idea to specify two different syntax forms, since that could also be confusing.

Hence, in my opinion, the best solution would be to mandate the (rx, ry) form for all register pair instructions (both in Zlisd and P), even if that would require more work in existing tools.

[christian-herber-nxp]

I appreciate your comment. However, any such solution would have to maintain consistency with Zdinx. This is an already ratified extension, so we cannot change it. Do you have a proposal to address this consistently?

[jnk0le]

arm uses straightforward rx,ry form for their ldrd/strd, no additional symbols around dst.

[christian-herber-nxp]

arm uses straightforward rx,ry form for their ldrd/strd, no additional symbols around dst.

Which version of ldrd/strd are you referring to? Thumb-2 ldrd/strd use two separately encoded registers instead of an even/odd register pair.

If you look at ARMv5TE, you will find this:

LDRD R4, [R9]            ; Load word into R4 from
                                   ; the address in R9
                                   ; Load word into R5 from
                                   ; the address in R9 + 4
STRD R8, [R2, #0x2C] ; Store R8 at the address in
                                   ; R2 + 0x2C
                                   ; Store R9 at the address in
                                   ; R2 + 0x2C+4

[anderslindgren-iar]

I appreciate your comment. However, any such solution would have to maintain consistency with Zdinx. This is an already ratified extension, so we cannot change it. Do you have a proposal to address this consistently?

Well, consistency between the extensions is very important, so a new syntax for register pairs should work with Zdinx instructions as well.

Given that, I think the best solution is to support both forms -- for all instructions that operator on register pairs.

[christian-herber-nxp]

Are you aware of a RISC-V instruction with two possible syntax forms?

[jnk0le]

Which version of ldrd/strd are you referring to? Thumb-2 ldrd/strd use two separately encoded registers instead of an even/odd register pair.

T2, just checked and it does actually address 2 independent registers even though all code samples always use consecutive. (n, n+1)

T2 (and A64) like syntax can still be used for a forced n+1 as well.

[christian-herber-nxp]

I just went through the isa manual. RISC-V defines one and only one mnemonic per encoding. Given that, I would suggest to raise this at isa-manual level to get the right discussion started. Because this starts with Zdinx.