Hi, I am facing a strange issue with the encoding of RRX assembly instruction for a project based on TI RM57L843 Arm_v7-R microcontroller: maybe there are bugs in the assemblers?

Here are simple examples of the 4 possible combinations of presence/absence of condition code and flags update for this instruction:

1 rrx r1, r0
2 rrxs r1, r0
3 rrxeq r1, r0
4 rrxeqs r1, r0

According to the documentation from ARM, all of them should be permitted by both A1 and T1 encoding, which in turn should be fully available in the ARMv7 architecture; but when one tries to use the 4 variants, the response depends on the selected Assembler:

* the gnu toolchain rejects variant 3, correctly encoding all of the others;

* the SEGGER toolchain rejects variant 4, while encoding all of the others.

Strange enough, when hand encoding in the simulator the proper bitcodes directly in the memory window, the disassembly window shows quite properly all of the 4 variants, and they are also executed flawless.

Any hint?

Hi mwb1100,
thanks for your response.

Indeed you highlighted another strange issue with the assemblers: when one sticks with the sequence of fields {S} and {cond} that is shown in the ARM manuals, which is exactly as you recalled, then one gets errors from the assembler for all of the instructions in the set, not only RRX - and this happens with both gnu and Segger toolchains!

On the opposite, when you invert the sequence from {S}{cond} to {cond}{S}, then everything works fine.

But, strange enough, when one looks at the disassembly window, the two fields are shown again in the sequence specified by the ARM manuals!

I got used to this strange behaviour, assuming it is probably some kind of heritage from initial confusion in the definition of the ARM syntax; so I did not mention it at all in my post, as it seems to be a systemtatic incoherence not related to the peculiar issue I spotted with RRX.

Hi mwb1100, Hi Nino,

indeed the problem is very quickly reproduced:
1) just create a new project in ES (last version: Release 7.32 Build 2023081802.53976 ; used in non-commercial mode, as I am an academic)
2) choose "C/C++ executable for ARM/Cortex-A/R processor" (2nd choice in the menu), then
3) choose for example the TI RM57Lxxx core (I also tried the brother core TMS570LC43x, did not try others but I guess the issue will be the same at least for any core in the ARMv7 - Cortex5-R profile),
4) choose either gcc or SEGGER compilers,
5) create an assembly (.s) file in the project possibly including just the following code:

.arm
RRX R1, R0
RRXS R1, R0
RRXEQ R1, R0
RRXEQS R1, R0

When I spotted this issue first I was in the middle of a much larger program, but the issue shows up neatly in any case.

When you try to build your solution, the outcome will depend on the toolchain selected for the project:

a) if the gcc assembler is selected, then you get a "bad instruction" error for the third code line; when this is removed, the remainig instructions will be correctly encoded;

b) if the SEGGER assembler is used, then you get the error "instruction rrxeq cannot set flags ..." referred to the fourth code line; when this is removed, the other instructions will be correctly encoded.

The fact that the 2 toolchains accept instruction variants which are rejectd by the other toolchain is obviously by itself an anomaly, but according to the pertinent ARM manuals, actually all of the 4 instruction variants are quite correct, so I have to conclude that both toolchains are failing in this case.

This is also indirectly confirmed by the fact that the SEGGER disassembler recognizes and decodes properly all of the 4 variants when you hand encode them and write directly the bitcode into the virtual memory of the simulator; moreover, when executed in the simulator both the third and fourth variants encoded by hand will work quite properly as expected.

My guess is that for some reason there are parallel but different bugs in the 2 toolchains, curiously both concerning the same assembly instruction.

By the way, Nino I also take the opportunity to highlight the systematic incoherency that I mentioned in my previous post while responding to mwb1100: the SEGGER disassembler shows the sequence of {S} and {cond} fields in full agreement with the ARM manuals, i.e. Instruction{S}{cond}, whereas both the SEGGER assembler and the gcc assembler will reject this syntax issuing a "bad instruction" error since they actually expect the inverted sequence Instruction{cond}{S} .

Being a systematic issue, once you realize it you can obviosly easily overcome it, but at the very beginning of my journey in the ARM world I felt somewhat disoriented and frustrated by the unexpected errors that I was getting from the assembler, so at minimum I would expect that such discrepancy was properly highlighted in the related documents.

Thanks and best regards
Paolo

Hello Nino,

thanks for your clarification: indeed I had not yet investigated the directive .syntax unified , since everything seemed working fine (just apart from RRX) once grabbed the issue related to the inverted sequence for the fields {S} and {cond} .

Anyway, good to know that using such directive permits to solve the specific issue related to RRX as well as to have a more neat correspondence with the ARM documentation: for sure I will be using it from now onward.

Thanks and best regards
Paolo