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

[Michal Sobon]

(Forgot to include the mailing list - apologies for the duplicate)

On Tue, Jan 20, 2026 at 11:10 AM Jan Beulich <jbeulich@suse.com> wrote:
> 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.

Sure. The doc is available here: https://archive.org/details/MCORERM
The relevant information is on page 83.

> >       * 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?
>

It was generated using objdump -drz and then manually modified to use
regular expressions.

> 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.

I thought of adding the new instruction at the very end of the .s file, this way
there wouldn't be a need to align these addresses. However, I see that
instructions
in this file are ordered alphabetically. Are you ok with adding the
BMASKI r3, 32 at
the end of this file? I believe this would make the patch cleaner.

> > -     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.

After adding the new instruction the whole file is 4 bytes longer, so
I believe the padding
is no longer necessary (not sure it was necessary prior to my change anyway).
I will add the explanation.

Michal