[PATCH] csky: Fix BMASKI disassembly for immediate 32 on C-SKY v1

[Jan Beulich]

On 29.01.2026 16:37, Jan Beulich wrote:
> On 29.01.2026 15:27, Michal Sobon wrote:
>> The C-SKY v1 bmaski instruction uses a 5-bit immediate field where
>> a value of 0 represents a 32-bit mask (all ones). Update the
>> disassembler to display "bmaski rX, 32" instead of "bmaski rX, 0"
>> for this case. This is consistent with the C-SKY v2 disassembler
>> which already displays 32 for this encoding.
>>
>> Add a test case for bmaski with immediate 32 in the v1 test suite.
>>
>> opcodes/
>> 	* csky-dis.c (csky_output_operand): Display 32 instead of 0
>> 	for OPRND_TYPE_IMM5b_BMASKI when value is 0.
>>
>> gas/testsuite/
>> 	* gas/csky/all.s: Add bmaski r4, 32 test.
>> 	* gas/csky/all.d: Add expected output for bmaski r4, 32.
>> 	Update branch instruction encodings affected by address shift.
>> ---
>>  gas/testsuite/gas/csky/all.d | 7 ++++---
>>  gas/testsuite/gas/csky/all.s | 1 +
>>  opcodes/csky-dis.c           | 3 ++-
>>  3 files changed, 7 insertions(+), 4 deletions(-)
> 
> Cc-ing maintainers.

Short of them responding, I will: Unlike for your earlier M*Core change,
the situation doesn't look as clear here. This is what I found in what I
hope is the applicable doc:

"When OIMM5 is 0 or 32, all bits of RX are set as 1."

and later, after discussing immediates 1...16:

"The range of immediate operand is 0 and 17-32."

Hence 0 looks to be a spec-conforming representation in disassembly,
albeit perhaps not as human friendly as 32.

Comparing with the v2 version of the insn also doesn't look quite fair:
That appears to take a 5-bit immediate in the range 16...31, with 1 then
added in.

Jan