[PATCH] opcodes: Fix BMASKI disassembly for immediate 32 on M*Core

[Jan Beulich]

On 20.01.2026 10:20, Michal Sobon wrote:
> The BMASKI instruction has three encoding variants (OMa, OMb, OMc).
> The OMa encoding (0x2C00, mask 0xFFF0) specifically represents
> BMASKI with immediate 32, encoded as IMM5=0.
> 
> Per Motorola M*Core specification: "An IMM5 value of 0 is interpreted
> as a value of 32."

Since M*Core doesn't have a maintainer, one of us not knowing the architecture
will need to deal with this. Trying to find a document along the lines of the
above, I do repeatedly end up with something that nxp.com calls "MMC2001
Reference Manual", but which then only has a list of insns without any details,
telling the reader: "Refer to the M•CORE Reference Manual (MCORERM/AD) for more
details on instruction operation." Unhelpful if such a doc cannot reasonably be
found on their website.

Can you please provide a link to permit double checking of what you say? It all
sounds plausible and is consistent with what the assembler looks to be doing,
but still.

> Previously, all three variants extracted the immediate the same way,
> causing OMa to incorrectly display 0 instead of 32.
> 
> Before: 0x2c04 -> bmaski r4, 0
> After:  0x2c04 -> bmaski r4, 32
> 
> opcodes/
> 	* mcore-dis.c (print_insn_mcore): Handle OMa encoding to display
> 	immediate 32 instead of 0 for BMASKI.
> 
> gas/testsuite/
> 	* gas/mcore/allinsn.s: Add test for bmaski with immediate 32.
> 	* gas/mcore/allinsn.d: Regenerate.

This last entry doesn't read quite right. "Regenerate" generally means
something that is generated by a script or program. I don't think that's the
case here?

> --- a/gas/testsuite/gas/mcore/allinsn.d
> +++ b/gas/testsuite/gas/mcore/allinsn.d
> @@ -63,336 +63,338 @@ Disassembly of section \.text:
>  0+024 <BMASKI>:
>    24:	2df3      	bmaski	r3, 31
>  
> -0+026 <br>:
> -  26:	f7ff      	br	0x.*26
> +0+026 <Bmaski>:
> +  26:	2c03      	bmaski	r3, 32
>  
> -0+028 <brev>:
> -  28:	00f4      	brev	r4
> +0+028 <br>:
> +  28:	f7ff      	br	0x.*28
>  
> -0+02a <bseti>:
> -  2a:	35e5      	bseti	r5, 30
> +0+02a <brev>:
> +  2a:	00f4      	brev	r4

As you had to touch all these addresses, did you wonder whether that should
actually be necessary? The next time someone adds an insn form in the middle,
the same would be necessary again. Are these addresses relevant for the test?
I don't think so, and if they aren't, I'd suggest that if already (almost)
everything needs touching, perhaps these should be abstracted away by using
e.g. [0-9a-f]+[02468ace] on the lines with labels (keeping the label names
properly spelled out). Ideally such would be done in a separate, prereq
change, but I wouldn't insist on that.

> --- a/gas/testsuite/gas/mcore/allinsn.s
> +++ b/gas/testsuite/gas/mcore/allinsn.s
> @@ -27,6 +27,7 @@ footext:
>  	test bkpt
>  	test bmaski "r3,8"
>  	test BMASKI "r3,0x1f"
> +	test Bmaski "r3,32"
>  	test br     .  // Dot means the current address
>  	test brev   r4
>  	test bseti  "r5,30"
> @@ -141,6 +142,3 @@ foolit:
>  	test xtrb3  "r1, r13"
>  	test zextb  r8
>  	test zexth  r4
> -	clrc			// These two instructions pad the object file
> -	clrc			// out to a 16 byte boundary.
> -	

This change is unexplained. From the .d file prior to the change it looks as
if the comment was stale already anyway. That's okay to correct here, but
wants mentioning in the description as a secondary change.

> \ No newline at end of file

>From the representation of the patch here it's not clear whether this issue
also disappears (it preferably would).

Jan